Share your CSS

Mermaid - Chart Widths

I found that when using Mermaid pie charts the chart would expand to fill all the available space. Therefore if you had a pie chart in a note with Joplin maximized on a large screen the pie chart was huge.

After some searching / experimenting I found that by adding the below to userstyle.css you can restrict the width of Mermaid charts.

svg[id^="mermaid-"] {
	width: 500px;

or maybe,

svg[id^="mermaid-"] {
	min-width: 200px;
	max-width: 500px;

There is also a “side-effect”. I previously reported an issue where having a flowchart without a “node” on its left side appeared to be cut off on its left.


This was closed as a Mermaid issue as it seems that when a chart is on the left Mermaid does not draw the “empty” line.

However using the above css moves the flowcart out from the left and the line is drawn!

This setting may cause problems for those with horizontal charts and possibly using % rather than px would be better, but hopefully it may assist someone else or act as a starting point for something better…

Edit: Added min/max-width variant.


What a weird question.
Clearly, plenty of us want to use userstyles, and don't care if they break sometimes. :wink:


I am not sure if this is applicable to your use case, but hitting Command-R (Mac) inside the Development Tools window force reloads the app, so you get CSS changes without having to restart the app.

Since I usually have that window open when I am messing with css, it was a little faster than restarting each time. Happened upon it by accident, so thought I'd share :slight_smile:



I have a vast archive of notes collected over the years (decades). I would really hate to see old notes suddenly looking different (even becoming unreadable/unusable) due to unsollicited changes in the rendering engine.

Even without custom CSS Joplin keeps changing note appearance from version to version, which I must consider a big disadvantage when it comes to serious, long term note taking and collecting.

Really. Since all the notes are just markdown, what could Joplin possibly do to make them “unreadabe” or “unusable”? It’s text files.

And if you don’t like userstyles changing the look of your notes, it’s actually very easy not to use userstyles. Someone else’s userstyles stop working because of Joplin’s internal changes? That won’t affect your notes one bit.

Btw, for me, this is exactly why I like my notes in Joplin: the chance I will suddenly lose access to them (and I include their becoming ‘unreadabe’ in that) is virtually nil.
Since this is a point of interest to me (I suspect for many of the same reasons as it is to you): what system/s do you currently use, instead of/beside Joplin?
I do realize this is veering off topic a bit, so feel free to DM me if that’s better.


Mine can be found here. For future readers, here’s a deep link to that file at the time I made this post: link.

You will need to have this font installed if you want it to look right.

I deliberately tried to create something LaTeX-like, because I work in that a lot and like the way it looks.


Thanks for this, huge time saver!

For anyone on Linux F5 in the dev tools does the same thing, I’d assume on Windows as well.

You can refresh really fast if you press Alt+H to open help, T to open devtools, then F5.


Hi, made a repo to share the first version of my dark theme if anyone is interested:

Thanks to everyone who shared their tips!


I've now added a warning in the app and moved the setting under Advanced Options to make this clear.

They are discouraged because indeed many users don't like when their style break from one version to the next, and that's understandable. However I won't make a commitment to keep the HTML structure stable as that would be the end of many improvements that could otherwise be made.

So that's why we allow usercss, as it's easy for us to allow it and many users want it, however it's your custom file so it's your job to update it as the app evolves.


Good. This creates a clear situation in which everyone can make their own decisions. Thanks.

I really like this one which is eye-friendly, even for a night mode; the example doesn’t show if it’s syntax hightlighting compatible ?

As I often use internal Joplin links “inline” I find that the Joplin internal link “J” icon before the link can be rather distracting.

This CSS is for userstyle.css and removes the “J” icon for internal links but does not remove the resource type icons for txt, pdf, zip, etc. attachments.

However as there is no longer something to differentiate between internal and external links it also changes the colour of internal links and, if applicable, their resource icons. In this example blue is external and green is internal.


a {
color: #0000CD; /* set general link colour - includes TOC links*/

a[data-resource-id] {
color: #006600; /* change the colour of INTERNAL links */

.resource-icon.fa-joplin {
display: none; /* do not display the Joplin resource icon */

.resource-icon {
background-color: #006600; /* change other resource link icons to the same as the internal link colour */

Hi, thanks for the tip, I didn’t realize syntax highlighting was available in markdown!
I hadn’t checked before, but yes, the theme supports it with the built in colors from the stock Joplin dark mode theme.


Thanks for this tip, it was really helpful. I wasn't familiar with the a[data-resource-id] selector before.

How are you adding the resource icons for different filetypes?

As for the Joplin J, I ended up just making it much smaller, will see how that goes. :slight_smile:
little J

If anyone wants that code, change this in userstyle.css. Might need to tweak it based on your font sizes:

.resource-icon {
    width: 10px;
    height: 12px;
    top: 0.1em;
1 Like

This was found not from any great CSS knowledge but just by looking at what others had submitted on this forum and applying it to elements identified using the Development Tools.

I saw that internal links looked like this

<a data-from-md="" data-resource-id="070417fe118d4f509a8d4076f90b4ab6" title="testfile.pdf" href="#" onclick="ipcProxySendToHost(&quot;joplin://070417fe118d4f509a8d4076f90b4ab6&quot;); return false;" type="application/pdf"><span class="resource-icon fa-file-pdf"></span>testfile.pdf</a>

and data-resource-id="070417fe118d4f509a8d4076f90b4ab6 could only apply to an internal resource link as the same id is used in the link itself.

So using something I have seen on this forum I tried to devise a selector which meant "Any a tag which also has a data-resource-id" and came up with a[data-resource-id]. No one was more surprised than me when it worked!

I haven't added any resource icons, they are built in. I just prevented one of them, the Joplin internal link icon, from being displayed.

Making the resource icons smaller seems a good idea especially if they become small enough to stop affecting the space between lines in a paragraph when used "in-line". Not tried that yet. I think you have also seen on another post that @laurent and @tessus have mentioned the possibility making the resource icons smaller by default. In the meantime I think I will play with your suggested CSS. Thanks for sharing!


The icons should have the height of a capitalized letter. The distance from baseline to cap height.

1 Like

Ah! Ha, I suppose if I just had never included a non-image link, good to know.

Ah, good call. My previous css sample didn’t work well at other font sizes. This looks much nicer IMO:

.resource-icon {
    width: 0.75em;
    height: 0.9em;
    top: 0.1em;

Not exactly cap height, but seems to work ok.
css cap height


Nice, much better. But the color of your links seems to be much lighter than mine? It has too little contrast for me now. I like the teal color but it is more darkgreen on my screen.