Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root


1 badge earned


Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!


Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.


Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!


Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

Confluence does not retain/use uploaded SVG images

When inserting an SVG image into a Confluence page, the SVG preview and view in the editor look OK. However, on a subsequent *reload* of the page, the image comes out garbled. It seems like Confluence is replacing the SVG (crisp and small vector graphics) with a JPEG image (pixelated, compression artifacts in scaling, larger in size).

I suppose the image converter used does not know how to handle fonts correctly (in this case `font-family="sans-serif"`), and replaces text glyphs with boxes/squares (see image).


PS: The handling of Markdown syntax in Atlassian product sucks. It is highly inconsistent!



2 answers

1 vote
Owen Wallis
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 19, 2020

Hi everyone,

Thanks for your patience with this.

I’m the PM on the Media team. The fact that SVGs render text as squares has not been great.

I’m please to say we’ve started rolling out an initial fix.

As some of you have noticed we are rendering SVGs as image files.

This is as some SVG files can contain script tags, so are vulnerable to XSS cross site scripting.

Our security team has helped us look into some libraries which parse the files and strip dangerous code. But unfortunately they don’t meet our standards, and would put your instances at risk. I appreciate its unlikely one of your team members would try and take advantage of this risk vector, but it’s just not something our security team are happy with.

So, we need to keep rendering SVGs as image files.

What we’ve therefore done is added font support for Arial, Times and Courier. So essentially a serif, sans serif and mono font which all fonts should fall back to.

I’m really sorry but this is a forwards only fix. So SVG files previously uploaded will not benefit from this fix.

I’d like to keep this ticket open as it may be there are some unicode characters we’ve missed out.

So do let me know if there are any other font sets which would be useful and we’ll do our best to incorporate them.

All the best


Thanks @Owen Wallis for the much appreciated input.

In that sense, it would be appreciated if the fonts used were not Arial, Times (New Roman) and Courier (New), but rather fonts maybe from the Noto [0] bundle (they have a much wider coverage of Unicode glyphs). The licence should be suitable for your purpose.

Additionally, if SVGs will have to be rendered as pixel images, I'd appreciate it if they were done so in PNG format (not the lossy JPEG format with compression artifacts), as that will be much more suitable for the use case (these are not family snap shots).

Thanks in advance,



(licensed under the SIL Open Font License)

Owen Wallis
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 19, 2020

Great feedback thank you. We'll take a look at Noto.

Agreed that SVGs are not family snap shots! PNG is more suitable so we'll take a look into that too.



Like Aleksandr Krymskiy likes this

@Owen Wallis Thank you very much for the explanation. I have a question: if the issue with keeping SVG without converting them to a flat-image format are script tags, wouldn't it be just simpler - not accepting SVGs that contain script-tags, etc. or stripping them immediately from the SVG XML upon upload?


Owen Wallis
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Aug 20, 2020

Hi @Aleksandr Krymskiy

Thanks for the comment. Yes I did ask the same question to the team. The issue is any malformed script tags (which we would assume a hacker would try and use) would result in us failing to parse, i.e.

<   script
name =">" > </script>

If we just parsed for the word 'script' then genuine SVGs that had this word (i.e. please students read this script) would be penalised.

Also unfortunately <script> is not enough, you can have onclick, onthis, as handlers in the SVG elements.

Overall security were not comfortable with the risk this entailed.

Like Mandy Ross likes this

That kind of issue sounds like there's a regular expression parser (rather than an XML/tag parser) in place, if it's that easily fooled.

For the kind of price tag one forks out on Atlassian stuff, I'd expect better ...

Things could be so much better if they were just done right.

Like # people like this

@Owen Wallis You have a parser and renderer to convert the svg image to the raster. Why you cant cleanup the svg? You could at least render svg to svg instead of a bitmap thus getting rid of any scripts.

Like Benjamin McCord likes this

I really feel like this should not be a difficult hurdle.  But I could be wrong.  Also, it is worth noting that according to mozilla's documentation if the svg is embedded as an <img> then scripting is disabled.  Of course, if a user opened the image directly this would still be an issue.  And its not clear if this applies to other browsers.  My approach would probably be to parse the SVG file and rebuild a filtered version.  I would use an actual DOM parser to do this.

0 votes
Shannon S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
Jul 02, 2020

Hello Guy,

I've had a look into this, and it appears you are running into the following bug:

  • CONFCLOUD-66798 Adding text to SVGs renders as rectangles on a second edit

I found an internal ticket linked to this one, and it looks like we've been able to replicate it on our end. 

There appears to not be a workaround for this, as Atlassian Cloud does not fully support SVG at this time. There may be an SVG add-on that could help you with this, or I would recommend using another format until the issue is resolved.

I understand this is not ideal, and I am hoping we can see a resolution to this in the near future.

Regarding the handling of markdown syntax, would you be able to raise a separate question regarding this? It's possible to insert Markdown using a macro. If it's not working for you, we'll need some specifics about what Markdown you were using, and where. By sharing this as another question, we can go more in-depth about it.

Thank you, and take care!


I am having the same issue after uploading SVGs generated from Visio. Can you add some sort of flag/setting preventing the "mangling" of SVG? I want to be able to provide a resizable diagram for the viewer, and there is no alternative format that is able to do this. I am unclear about the "Atlassian Cloud does not fully support SVG" - it does not need to support it - it just needs to not mess with it as recent web browsers are able to display SVG natively.

I am not able to see linked CONFCLOUD-66798 - would be curious to see more detail about the bug.


So, it clearly looks like Atlassian needs/should do something about it. Either by disallowing the use of SVGs up front, or by just not messing with them (converting them to a pretty stupid format for usually line drawings (JPEG) in the first place). Can it be so difficult? It's done all over the place, and especially for Confluence this would be quite useful. Especially for a product one must pay so much money for every month, and that has long recorded issues.

I also think that add-ons are not the right solution for something that should actually work straight out of the box already. Especially as most add-ons require (A) additional subscription fees and (B) make the situation even more messy with even more unrelated (3rd party) domains resources are pulled from. What a nightmare from a security and privacy perspective, also causing additional issues with 3rd party T&Cs as well as jurisdictions (for those that may e.g. have to deal with GDPR and such).

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events