Is custom CSS not allowed in Confluence Cloud?

I don't see this option as listed in the help documentation.

5 answers

1 vote

Your instinct is correct - see for the list of things that are restricted on Confluence Cloud (custom css is buried in the middle)

Why are these things restricted ?

Is my money somehow worth less than a corporate blue-chip ?

Most things that are restricted in Cloud are restricted because Atlassian support do not have the time, money or will to support it when a user gets it wrong.

A lot of the restrictions have been implemented based on the volume of support calls received that lead to lots of time chasing down configuration mistakes on server.  CSS was one of the more expensive ones.

If you find apps which do theming and allow CSS, that's fine for support, because Atlassian have low-cost routes to fix it - they turn off the app and if the problem goes away, it becomes the customer and app vendors problem, not theirs.

Then perhaps I should cancel my subscription entirely and seek an alternate online cloud solution.

Any content tool such as this should at the very least provide custom CSS support and configurable classes placed on elements.

Seems to me like the excuse of "excessive support" simply suggests that cloud solutions are not viable. You can't simply remove functionality because user's get confused. It just needs better documentation to allow the users to not get in a mess to start with.

I'd point out that Confluene is a tool for collaboration, not being pretty.  Personally, I'd like a little more control over the look and feel, but if I'm going down to css level, I'm probably going too far.

When you have users who are confused and likely to make a mess that costs you time to fix for them, you have two options - charge them more so you can afford to fix their problems, or stop them doing making a mess somehow.  In this case, Atlassian chose the latter.

The problems they've burnt support time on in the past are because of the users who don't read the documentation or learn css properly.  It doesn't matter how wonderful your docs are if they're ignored.

"not being pretty"... ok... I give up... you win...

Confluence is just an example of a company that cuts features to save money. If you feel you can find a product that suits your needs, and if you feel that confluence is missing core features that your money should cover; then stop giving confluence your money. It's your right as a consumer to vote with your buck.

I'm afraid your statement about cutting features is completely wrong.  It's about support, as already discussed above.

Voting with your wallet - yup.  I'd challenge you to find a SAAS competitor to confluence that lets you break it and hence impose support costs at a similar or lower price though.

I have to agree with Paul, that is a quite ridiculous statement.

Customising the appearance of a system does not open that system to being 'broken'. To deny that as a feature means people simply look for an alternative product, not an alternative hosting solution. My self-hosted Confluence allows me to customise the layout and styling, and that is supported by Atlassian.

Championing a product and justifying shortfalls with inappropriate excuses are not the same thing. For tech-support to not support user customisations is commonplace, and it's normal to instruct a customer to revert to the default 'style', and if an issue can't be demonstrated there then it's their own issue. Given that the self-hosted solution does support these features seems to invalidate this whole argument.

Confluence does let your solution look pretty, and it does it very nicely indeed! It's a fantastic editor environment, and we can add a new example or information snippet at any time online, whereas with something like Help'n'Manual we'd have to load up a Windows application, edit content, then generate output.

The issue we have is that while we have fantastic content, we have a dogs-dinner of a default presentation template, with a dreadful left banner area and a locked Confluence logo at the top. So instead of winding people up by suggesting they are somehow requesting inappropriate features, perhaps you could suggest solutions or workarounds?
The 'Instant Websites' plugin supports these features on the cloud platform, but it seems like extortion to make users pay $25/month simply to add custom CSS or change a layout on a $10 hosted site!
If they're not cutting features to save money, perhaps they're deliberately excluding them to force people to buy expensive addons and taking their percentage from the marketplace? It certainly appears to be one or the other.

No, you've completely missed the point I'm afraid.

Let me rephrase it.  You look after a system that allows the user to break it.  Do you really want to spend time and money fixing it when they do?

So, given that argument, why does the system allow me to embed hyperlinks? You could argue that allowing hyperlinks can cause people to "break the system". Is this because you think any attempt Atlassian made to allow custom styles would be riddled with security loopholes?

Just assume I'm ignorant with regards to some basic feature of css styling... can you explain to me exactly which aspect of allowing custom css on my Space would break Atlassian's Confluence system on the cloud based platform?

Also, if it's likely to break the system, how do I prevent the same thing happening on my self-hosted deployment?

From my point of view I'd imagine something like the following happens a fair bit;

  1. Admin A gets a request to hide the Sidebar for some users and so does it with custom CSS. (There's a guy further down the thread that actually has asked this)
  2. Less technically able Admin B gets a complaint from other users that the sidebar has vanished and hasn't been informed/talked to Admin A.
  3. Admin B logs a support ticket with Atlassian about their broken system...

Assuming the above holds true (I could have a bad assumption here). If you have a self-hosted system it makes sense that any problems with the system would go through Admin A (or whoever the tech support team is) so they would be aware of this kind of changes or how to figure it out. In this case, the first line of troubleshooting/support isn't Atlassian for self-hosted deployments so more customization is OK (This is just my assumption though, I'm only a cloud user).

In the cloud system, you just go straight to Atlassian support when you have a problem, so preventing the above kind of scenario when you have a lot of users makes sense.

Like 1 person likes this

In this case I'm against Atlassian decisition.

Confluence is a tool that NEEDs customization. Put warnings in every colour and size you want telling the user that if he enables customization he will lose support and make it clear that is only for advanced users.

Use case:

Recieves an incident? First, disable customization. It works now? Then we don't support your problem. Hire a better developer

Like 1 person likes this

Or, better, stop them doing it, so you never have to field any support.

>You could argue that allowing hyperlinks can cause people to "break the system".

How?  You could link to a bad thing, but that would be outside the system you're supporting, so you don't care.

>Is this because you think any attempt Atlassian made to allow custom styles would be riddled with security loopholes?

More usability than security.

>Just assume I'm ignorant with regards to some basic feature of css styling... can you explain to me exactly which aspect of allowing custom css on my Space would break Atlassian's Confluence system on the cloud based platform?

>Also, if it's likely to break the system, how do I prevent the same thing happening on my self-hosted deployment?

I've spent weeks having to remove css that hid things, re-rendered things incorrectly and then needed to be updated because Confluence changed.  It can be a nightmare for an admin, but that's what I was paid for at the time, and it was part of the job.   There's nothing to stop you getting it wrong on server, but you're choosing to support it yourself.  Atlassian's choice for Cloud is "prevent the problem completely, so we don't have to support users who break it". 

Note the point about upgrade too - Confluence on Cloud can be changed week to week (although it's usually more like 3-6 weeks), and do you really want to have to handle a swathe of support calls because someone has done something that breaks because of your deployment every 6 weeks?  Not at the price Atlassian sell Cloud systems for.

This is not about allowing customisations or forcing people to get add-ons.  It's about not having to support other people breaking stuff.  If you don't want someone to shoot themselves in the foot and then cost you for the medical help, then it is easier and cheaper to not give them the gun in the first place.

Wow, given this type of justification it's amazing users are allowed to type their own content at all, rather than restricting content to selection from a predefined list of phrases!

Seriously though, Confluence Cloud is possibly the only web based service I've ever used that refuses to allow custom CSS. It's such a weird argument to suggest that every other web based system out there suffers under a deluge of profit destroying (or even effecting) support calls related to an unexpected piece of CSS.

I think you need to climb down and view things from a more realistic perspective. Confluence is the tail, not the dog. I'd like to hear from Atlassian themselves the reason these unique Atlassian restrictions exist, and I don't believe they have anything to do with the reason you mention.

Oh, and we have licenses for Confluence with support agreements, and we run on EC2 instances. I can edit the templates and the CSS, as can my staff, and if one of us accidentally added a `display: none` to an element I can contact support and ask them to help me. Is this in some way different to the Cloud hosted situation?

@Nic Brough [Adaptavist] This is is a complete cop-out. While CSS does have the power to break the user's portion of the site, it can be easily negated with an option to switch views to the default CSS at any time. This allows the users to help themselves rather than rely on support (which most of us would prefer anyhow).

As someone who has worked on SaaS platforms for several companies, I know there are probably 100 different ways to make this work for clients while minimizing the risks to Atlassian. Unfortunately, this is a systemic problem with Atlassian in general believing it knows better than its users, and as better products come along the market will shift towards those products.

In the last few years I've run into a number of Jira and Confluence bugs and feature requests for relatively basic functionality that Atlassian has either ignored or attempted to excuse (poorly) such as this one. As usual, in the end the users are left to find hacks and workarounds.

Add me to the list of people voting with their wallet. I will no longer recommend Atlassian products (with the exception of OpsGenie, if you manage to not screw that up too bad), and will instead work to find solutions for my clients and businesses that have a track record of fixing issues instead of arguing why they aren't issues.

There is no official way to use custom CSS, but there is a workaround. As part of the Content Formatting Plugin (included in Confluence Cloud), you have the CSS macro. You can embed this in one particular page, or you can also include this for all pages in a space/instance by including it in the space/instance header/footer options in the following format:

//CSS code goes here

You can also add CSS to the Styles field of some macros instead of using the CSS macro.

Didn't work for me; I put the following in my header and footer and it apparently gets overridden by something in Confluence Cloud during page load; goes back to #515151

{style}#title-text{color: red}{style}


{css} is no longer a valid macro in Confluence Cloud

If you want to change the title color, then the following should work on Confluence Cloud which hasn't been upgraded to the new style:

{style}#title-text a{color: red}{style}

If you've been upgraded to the new ADG3 style, first of all, header and footer text doesn't appear to be working (as of this moment) at all. Secondly, even if it was working, the content of the page is now displayed in an iframe, so the style macro will only affect page content and can no longer affect anything outside of the page content frame.

We must be using the new ADG3 style.



Ask them how many support calls they've had that ended in "client has messed up".  Wouldn't you want to shut those down?

@Nic I would agree but they support site-wide and Space-wide stylesheets with self-hosted configurations.

That's got nothing to do with supporting Cloud.  Different beast entirely.

It seems that CSS in the header/footer does not longer work in the new layout.

Does anyone have a solution for this instead adding the css-macro to every page?

Possibly: in talking with some managed hosting providers, one mentioned they would theme our site based upon this add-on -- which is compatible with Atlassian Confluence Cloud:

Kerching.... $$$

It seems that in the current cloud you can put this into the footer code and it works.

code {
color: #c0341d;

This is kinda hacky - I would very much prefer the unsupported macro warning to be on the footer input form in admin, not when it's rendered, but I can hide that for now and kinda understand why it's there.

FYI; I've omitted that code to hide the warning, if you know what you're doing you'll find it yourself - if you don't know enough to be able to do that I'd wager you're probably in the group that caused this feature to be disabled with support requests...


Using the footer to hide the sidebar doesn't work for me, but if it works for you I'm sure I did something wrong. Can you verify that it works?

I can confirm that it does work, though if you do this any issues arising from it are going to be all your own fault and Atlassian support probably will be less helpful when they spot that. I would definitely not recommend you do this, hiding the sidebar will cause all sorts of pain for your users in addition to the above.

That said, I played around a bit and found the following;

It will depend on the particular template that you used to create the page - I noticed that new pages seemed to work but some older pages don't seem to have the Footer/Header rendering at all.

Recommend that you check with some text that your page template is rendering the Footer.

You also get a nice warning message if it's being rendered telling you exactly how much support you'll get if you do this.

Test 1234 - Testing - Confluence 2018-12-03 19-36-41.png

Thanks for this!

So I suggest you add in this part too. It will hide the warning message you get.

I posted this into the Footer.


[class^='SpaceCustomSettingsBlockComponent_unsupportedMacros'] {
display: none;

code {
font-family: Monaco,Menlo,Consolas,"Courier New",monospace!important;
font-size: .75rem;
line-height: .75rem;
white-space: normal;
color: #e01e5a;
padding: 2px 3px 1px;
-webkit-font-variant-ligatures: none;
font-variant-ligatures: none;
tab-size: 4;
-moz-tab-size: 4;
-o-tab-size: 4;
-webkit-tab-size: 4;
background-color: #f7f7f9;
border: 1px solid #e1e1e8;

Like 1 person likes this

Hi @Richard Hodsdon

I tried you solution but I'm afraid it's not working.

I actually omitted that part from my comment for the exact reason of not wanting people to ask about why it's not working (and I think an admin may have deleted my comment when I included the code)

It may be different in your case based on the page template and a whole load of other variables. I don't really recommend trying to hide the warning unless you are familiar with and are willing to figure out the CSS selectors on your own. It's not really something anyone can help you with - you'll have to figure it out yourself why it's not working (though stack overflow may help with figuring out the CSS/styling problems - also in chrome "Inspect Element" from the right click menu)

As Simeon above says, it could be different for an installation.


@Simeon Cheeseman I only saw your FYI after I had posted it :) But thank you for at least getting me in the right direction.

Like 1 person likes this

I was able to make it work. I think I was expecting it in the editing mode as well. My bad. Thanks!

I'm raising a support ticket to ask how to change link colours in Confluence spaces that appear in service desk portals.

Guess the cutting support thing doesn't work entirely.

Suggest an answer

Log in or Sign up to answer
Community showcase
Published Mar 12, 2019 in Confluence

Confluence Admin Certification now $150 for Community Members

More and more people are building their careers with Atlassian, and we want you to be at the front of this wave! Important Dates Start the Certification Prep Course by 2 April 2019 Take your e...

1,208 views 2 13
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you