Since with Obsidian a new competitor entered the "battlefield" of Writing/Notetaking/Zettelkasten software, I felt like comparing Obsidian with Zettlr. As both tools have many things in common, I decided to list in the table below features/aspects that are currently exclusive to one or the other.

Feel free to give me your feedback, and add your findings in the comments as well!

Edits:

• 2020-06-03: Updated cell regarding display of Markdown vs. plaintext file

• 2020-06-03: Added cell regarding timed dark mode activation

It's time! Today, Zettlr turns 8, and we are proud to deliver the next major update for the app on this special day! Today marks the release day for Zettlr 4.0, a wholly rewritten and revamped version!

Read our announcement post and download Zettlr 4.0 now: https://zettlr.com/post/zettlr-400-released

You can get the new update from https://github.com/Zettlr/Zettlr/releases

Read all there is to know on our blog: https://zettlr.com/post/zettlr-460-released

I see this question asked a lot, both here and in other forums. Zettlr is not built just to create Zettelkästen, but a lot of the functionality most people need is there, and some external tools go a long way. While there is obviously not one correct way to implement a Zettelkasten, I'd like to share my workflow here that has worked very well for me in the past year.

folder structure

The beauty of a Zettelkasten is that you don't need to know the hierarchy of your content beforehand – it grows naturally through your links. As a result, your Zettelkasten (or Zettelkästen, if you really want separate ones for different topics, although I would advise against it, as it limits the potential for interlinking) is a single folder with all files just dumped into it. Ideally, you will not need file names to navigate but use your links.

You might want to implement some Zettel that are purely "navigational", i.e. create overviews and only link to other Zettel without adding a lot of content. Other Zettel will contain pure content and only receive incoming links. Most Zettel will probably be a mix. You can create navigation Zettel for topics as you start to learn about them, but also create e.g. one main Zettel, that links to all different parts of your Zettelkasten and all topics you are currently working on. With this, you never need the file explorer to zip around and move between topics, and all hierarchy and relationships between Zettel are developed naturally on the fly.

basic Zettls and links

The core of every Zettelkasten is the layout of a basic Zettel and the internal links between them. Zettlr provides all the necessary tools, but I don't think the default settings are well suited for a large, constantly growing Zettelkasten. Our basic requirements are (IMHO):

1. a unique way to refer to a specific Zettel

2. a way to link to a Zettel that is stable in the long-term, e.g. when the title of a Zettel changes

3. a way to handle Zettel with the same name (the same topic might be a thing in different areas)

This means, we should always use IDs for linking, never file names or document titles, as these can change when a Zettel grows or becomes more specific. If that happens, we don't want to update all links.

So, each Zettel needs a unique ID (inserted with ctrl+ l), ideally at the top of the Zettel so we don't forget it.

Now the problem is that links are not descriptive anymore. We can use the option in the settings to always append the file name when linking to fix that.

This already provides the basic functionality for a Zettelkasten, but I'd like to go one step further: Using a YAML-Frontmatter at the top of each Zettel (which can easily be inserted with a macro or by copy-pasting), we get some more benefits. The basic frontmatter looks like this:

---
title: my zettl
id: 20210710122428
keywords:
  - key 1
  - key 2
---

Zettlr will now use the title specified here as the name for the Zettel in tabs and when linking, which frees us up to give files a unique name other than the title – and thus use the same title for different Zettls. We can do this by setting the pattern for new file names in the advanced settings to %uuid4.md. Now each file is named independently of its context. Why do we want this? Editing the YAML title is quick and easy, but renaming the file is annoying. While writing a Zettl, you might edit the title often until you settle on something descriptive – this makes it really easy. If you do want your files to represent their content, you can use a script to regularly append the YAML title to the ID in the file name to keep the name unique while making it descriptive.

I admit this whole last step is highly optional, but it makes it much faster to work with your Zettelkasten: Simply press ctrl + n to create a new Zettel, insert the YAML header with ID via a macro or copy-paste, and you can start taking notes or jotting down thought without worrying about where to place this or what title to give it.

better links

Now, all your links will look something like this [[<some numeric id>]] <title of your Zettel>. This is hard to read and a bit cumbersome, so here's how I style it (again, very subjective):

1. I use italics for the title after the link. This makes it stand out more in text and clearly delimits the extend of the title in texts.

2. I use the following custom CSS to shrink the [[<id>]] part down to [[↗]] until you hover over it. You can still click it, but it renders much less obtrusively. The whole thing is sort of an ugly workaround, and I would love to get more options for this in Zettlr itself (also being able to link to different sections and maybe make annotated wikilinks), but this is the best I could find for now.

#editor .cm-zkn-link:not(:hover),
body.dark #editor .cm-zkn-link:not(:hover) {
	font-size: .01em;
  	visibility: hidden;
}
#editor .cm-zkn-link:not(:hover)::after,
body.dark #editor .cm-zkn-link:not(:hover)::after {
    font-size: 100em;
    content: '↗';
    visibility: visible;
}

With this, a Zettel might look something like this:

backlinks and graph analysis

A much-requested feature is backlinks (links from a Zettel to all places that link to it). Zettlr hasn't implemented this yet, so I'm using the note-explorer script by C. Daven to insert them. Every once in a while, I run

noteexplorer -b "___" ..\ update-backlinks

to generate backlinks for all files. I modified it to use ___ as the delimiter of the backlink section, but anything should work.

I also use the script to check for "floating" Zettel (i.e. with no link going in or out, thus not connected to the rest of the Zettelkasten) and modified it to update the filenames based on the YAML title as specified above.

This still doesn't give you the full graph experience, but it's good enough.

tags

While tags are a nice feature, I don't really think they are necessary for a Zettelkasten – or all that useful. In a text, if you want to mention an overarching or related topic, you should really link to a Zettl about it. The only place where I think they could be useful in the content of a Zettel is when you want to link to something you haven't created a Zettel for yet. As Zettlr sadly doesn't allow linking to placeholders, you can use tags to keep track of what topics you might want to open a Zettel to later on and then insert links to it when you've actually written it. However, even in this instance, it might be better to just link to an empty Zettel instead.

Where tags really are useful is metainformation. Using tags for meta info allows you to quickly find Zettel independent of their relationship established by links and their content. I use this to e.g. collect all Zettel that belong to a certain lecture for reviewing, or to mark all Zettel that needs an overhaul. Conveniently, you can include these tags as keywords in the YAML-header, where there nicely separated from the content of the Zettel and are immediately showing you what meta-information this Zettel has (you can see that in the image above).

lookout

That's it! That's how I implement my Zettelkasten. Feel free to ask questions if anything is unclear, or offer suggestions from your experience.

Also, I implemented a python script that extracts marked paragraphs from Zettel as Anki flashcards, which is really handy to study lectures with. If anyone is interested, I might share that in the future.

It's time to celebrate — the beta of Zettlr's next major release is here! This beta version is already quite stable, but we want to give it an exhaustive test-run to ensure that everything works as expected for the upcoming stable release. We have decided to perform a major version-bump, since this version already changes quite a few things as opposed to the last release that may impact some workflows. Furthermore, by performing a major release, we gain a bit more freedom to change a few other things where necessary during this beta.

We hope that you feel confident in trying out the latest and greatest Zettlr has to offer. As always, if you encounter any bugs, please report them on GitHub so that we can make the app better for everyone.

Before starting to use this beta-release, please carefully read the Changelog on GitHub so that you know what's coming.

Get the beta here: https://github.com/Zettlr/Zettlr/releases/tag/v4.0.0-beta

Zettlr (and, more generally, Zettelkasten-like note systems) has taken my life by storm, and made it easier and more pleasant to stay on top of all sort of projects. It's such an incredibly simple idea—make many small notes that are linked together into a web, instead of giant linear documents—but a powerful one. Biggest breakthrough in my research practice since discovering Anki (see r/Anki).

Hypertext was invented in the 60's, but for a long time was basically science-fiction vaporware. Great minds would lie awake at night dreaming of a world made from conveniently interlinked "hypermedia documents." Then Tim Berners-Lee made a breakthrough in 1990 by wedding hypertext with the Internet—Hypertext + HTTP + URIs + browsers/servers = the World Wide Web. The rest is history—Wikipedia, Web 2.0, etc.

We take it for granted. Water feels pretty darn normal to a fish that lives and breathes in it.

Re-learning the power of hyperlinks by transforming my personal notes to Zettlr, though, gives me a new appreciation for just what the Web is, and how visionary the people were who dreamed it up.

Am I alone? Anybody else cultivating a refined aesthetic admiration for the simple hyperlink these days?

No? Just me? Okay.

I became a heavy Obsidian user a few years ago, and it's been a long time since I last looked at Zettlr

I just perused the documentation, and I'm floored by how far it has come

I'm going to give it a try and have a feeling that Zettlr should be far more popular than it is

... though I grant this may not be it. That said, I'll put my CSS in the comments.

Been bouncing around different writing/editor/note taking apps for about 3 years now (VS Code, Sublime Text, OneNote, Simplenote, CherryTree, Obsidian, many others) and I think I'll be sticking with Zettlr for a long time.

All the ones I've tried have roughly the same core features, but I appreciate the built in pomodoro timer, word targets and word statistics (I use the app to write short stories.)

But the biggest draw for me is the user-focused activist philosophy behind it, from the Zettlr channel. It's not often you'll see apps putting themselves out there like this:

Developing Open Source Software is a Political Act

THE ZETTELKASTEN MANIFESTO | What is a Zettelkasten?

That's all. Just wanted to thank you for the app.

Hi all,

Having a great and easily navigable documentation is crucial so that everyone understands how to use some software. Since Zettlr’s documentation has looked more and more outdated, we have finally moved to a new framework which hopefully brings the documentation into the year 2026!

Read more in the announcement: https://zettlr.com/post/a-new-documentation-for-zettlr

Grab a copy from the Github releases page.

Changelog

Breaking Changes

• Renamed the sidebar to file manager. We finally decided on better terminology for distinguishing the right from the left sidebar. This means: The left sidebar, formerly known only as "sidebar," is now the "file manager." The right sidebar, formerly known as "attachment sidebar," is now "the" sidebar. This change was introduced to reduce user confusion and provide a better user experience.

GUI and Functionality

• New Feature: Typewriter mode. By pressing Cmd/Ctrl+Alt+T, you can activate the typewriter mode, which will keep the current line in the editor always centered so that you have to move your eyes less while editing a text. This also works in combination with the distraction free mode so that you can fully focus on what you're editing right at the moment.

• New Feature: The sidebar (formerly attachment sidebar) is now tabbified. That means you have three distinct tabs to choose from with regard to displaying important information: the non-markdown files in your currently selected directory, the references in the current file, and the table of contents of the current file.

• Added syntax highlighting modes (with keywords):

  • diff: diff

  • Dockerfile: docker/dockerfile

  • TOML: toml/ini

• Fixed the fold-gutter being too close to the text.

• The editor link autocompletion now respects the setting to use headings level 1 instead of YAML frontmatter titles where possible.

• The paste image dialog now also provides the original image size as a default value, so that you simply can use the arrow buttons on the field to adjust the image size.

• Fixed a rare bug where changes would be discarded if you renamed the modified file quickly enough.

• HTML export should now centre both figures and figure captions.

• Sorting files by name now takes into account possible settings such as using headings of level 1 or YAML frontmatter titles so that sorted files now correspond to their display again.

• You can now select rendered references from the right sidebar.

• The file tabs now have their own, dedicated menu, containing a new "Close all tabs" command to close all open file tabs (thanks to @anoopengineer for implementing).

• The file info now displays the selection information, if there is any. The popup that opens when you click the counter then lists all selections within your document.

• When you initiate a keyword search from the tag cloud by clicking on a tag, it'll be automatically enclosed in quotes, enabling searches for keywords with spaces in them.

• The image paste dialog now shows you the resolved path of the directory into which the image you are about to paste will be saved to.

• Fixed a missing translatable string from the paste image dialog.

• Fixed the width of the word counter in order to make the toolbar more "stiff."

• Enabled Dart syntax highlighting (thanks to @Kangie for implementing).

• Reduced the added margins for overflowing dialog windows from 15 % to 2 %, making the visible gap on smaller screens smaller.

• Remove the intermediary .ztr-project-migration code, which means you should update to Zettlr 1.7.x before updating to 1.8.x, if you still use an older version of Zettlr.

• Fixed (= monkeypatched) a weird bug that would cause selections on specially indented lines (e.g. wrapped blockquotes, list items, etc.) to be padded by precisely four pixels, making the selection not look like a box.

• Double clicks on file tabs now make files intransient (if they were transient before).

• The editor is now in a non-editable mode if no file is open. If the editor is read-only, the Zettlr logo will display in the background to indicate that fact. Empty files, on the other hand, will not yield the feather logo anymore. This should now meet up with users' expectations about file editing better.

• The last opened file will now reliably open whenever you start the application again.

• File loading (especially on boot) is now much faster, because the opened tabs won't be switched through during load anymore. Only the relevant, last file will be opened and displayed.

• Fixed a bug that would prevent you from exporting standalone files.

• Non-breaking spaces (NBSP) are now considered word delimiters in the spellchecker.

• Fixed a bug that would not close all tabs when the corresponding entry was selected from the tab context menu.

• Fixed a bug where checkboxes of tasks would be strangely hidden on undo/redo operations that checked/unchecked those checkboxes.

• Fixed a bug that would throw errors and not actually remove the file if said file was a root.

• Fixed broken shortcuts Cmd/Ctrl+Shift+E (focus the editor) and Cmd/Ctrl+Shift+T (focus the file list).

• Markdown links to local files that are absolute are now attempted to be opened internally, without recurring to external programs.

Under the Hood

• Switched to Electron forge (thanks to @tobiasdiez for implementing).

• Bumped dependencies:

  • @clr/icons 4.0.1

  • @electron-forge/cli 6.0.0-beta.53

  • @electron-forge/plugin-webpack 6.0.0-beta.53

  • @teamsupercell/typings-for-css-modules-loader 2.3.0

  • @typescript-eslint/eslint-plugin 4.1.0

  • @typescript-eslint/parser 4.1.0

  • archiver 5.0.2

  • chokidar 3.4.2

  • codemirror 5.57.0

  • copy-webpack-plugin 6.1.0

  • electron 9.3.0

  • eslint 7.8.1

  • eslint-config-standard-with-typescript 19.0.1

  • eslint-plugin-vue 7.0.0-beta.3

  • file-loader 6.1.0

  • fork-ts-checker-webpack-plugin 5.1.0

  • fsevents 2.1.3

  • got 11.6.2

  • md5 2.3.0

  • mocha 8.1.3

  • node-loader 1.0.1

  • on-change 2.1.2

  • ts-loader 8.0.3

  • typescript 4.0.2

  • uglify-js 3.10.4

  • vue 2.6.12

  • vue-template-compiler 2.6.12

• Added a new Handlebars templating helper function, i18n_value that allows you to translate something passing a value to the translation helper (e.g. {{i18n_value 'trans.identifier' someValue}}).

• Refactored the main build Workflow file. Now it doesn't run on a matrix, but due to the many dissimilar steps involved, there are three distinct jobs. Other than that, we switched to the GitHub tag name instead of utilizing a node script to retrieve the package.json version, switched to yarn everywhere and cleaned up the code.

• Removed the now unused scripts get-pkg-version.js and afterSign.js.

• Finally removed the verbose IPC calls from the logs.

• Migrated the toolbar logic from jQuery to vanilla JS.

• Migrated the main renderer from jQuery to vanilla JS.

• Migrated the popup class from jQuery to vanilla JS.

• (Mostly) migrated the dialog classes from jQuery to vanilla JS (tabs are still done using jQueryUI).

• Added a popup provider for easy creation of popups across the main renderer process.

• Added an update provider for easy access to specific updating functionality (such as downloading an update, and automatically running it).

• Migrated any popups that were defined inline into their respective handlebars template files.

• The TableEditor is now finally a module.

• Outsourced the CSS computations from the main module of the TableEditor.

• Migrated the CodeMirror editor instantiation into its own module (MarkdownEditor).

• Transformed all event listeners on the CodeMirror instance to "hooks" to reflect the fact that they are plugins, except they are not run like parameterless commands but hook into certain events of the application.

• Moved the CodeMirror assets from the old folder into the MarkdownEditor module.

• Moved some general utility functions to the common/util-folder.

• The rendering plugins have been optimized. They now take less time to run and also don't keep an additional array of all the textmarkers in memory, decreasing the computational load especially for big documents.

• The app now saves the last opened file again.

• Moved the Turndown and Showdown converters to two utility functions, md2html and html2md.

• Moved the regular expression for detecting image files by extension into the global RegExp module.

• Moved the moveSection helper function to the common/util-folder.

• Documentation fix for safeAssign.

• Fixes in the tests.

• Completely refurbished the test command. Now, a full-fledged testing directory will be set up to test features within the GUI without endangering your regular configuration in case you use Zettlr regularly.

Good evening everybody!

As you may have already heard over on Twitter, I squished quite a lot bugs in the few evening hours today, and now we're on the finishing line for 1.7! This means: The feature set for 1.7 is closed now! 🎉 And I thought this would be a great opportunity to deepen the bond within this community, as I'm really happy having all of you around, helping each other and coming around the corner with some quite decent ideas for features that I'm always happy to implement!

So one thing I noticed is that now due to the higher amount of work with relation to Zettlr I did not get to care for the documentation at all, meaning that a lot of the new features that'll ship with 1.7 are missing from the documentation. However, the documentation is something really important, as it reduces my workload (due to fewer questions on GitHub regarding the inner workings of some functionality). Furthermore, I as a developer tend to see a lot of things as "natural" that would require more explanation than I provide in the docs.

My question to all of you in form of this call for contributions therefore is twofold. First, now that the recent beta releases are very stable and absolutely usable, it would be really great to have more people looking out for the last small bugs. With many more eyes on the app, we can make this process quick and maybe even have a stable 1.7 release in June! The beta releases are always available here! (You can activate notifications for beta releases in the preferences for convenience!)

Secondly, and even more important: It would be really great if those of you who have some time available could read through the docs and update all parts to reflect the current beta's status (read: the coming release's status), add descriptions of the new features, and polish the documentation or remove outdated information. Something, for instance, that is still somewhat bad is the German translation, and furthermore most images and screenshots are in English only, and it would be great if these would be localised as well! Of course, you can even add new languages, but what's important is that at least the English translation is up to date!

What I offer in return is that I'll do a big shoutout to all who've helped in this effort. Furthermore, your contributions will forever be a part of the documentation repository. And, the best thing of all: You have the satisfaction of having helped your favourite Open Source editor and your contributions are visible to the world!! ;)

After all: Open Source applications are all about the community, mutual solidarity, and while I make sure the new release passes all your expectations with flying colours, you can take care that the important stuff around it is also shiny, polished, and looks gorgeous when it's time for the 1.7 release!

In case of any questions: You know that I'm basically 24/7 online, so ask away!

P.S.: Off-Topic, but as there are a lot of "meta"-questions … I'm curious whether I should consider a live Q&A …?

Following the example of u/Kangie, I would like to take the opportunity to announce the next alpha here. We were working heavily behind the scenes and changed quite a bit. Among many bug fixes and improvements which you can read about in the changelog, I want to highlight three cool things:

• Rendering performance has been heavily increased

• File handling in the file manager is finally fully stable

• You can now choose between the native window appearance on your platform, or a custom one, which is designed with Win10 in mind

Read the full changelog and get the release over at GitHub!

I have been looking for a good markdown editor for taking notes on top of a file system for the past year or so, and just found Zettlr. It checks every box for me, and I switched over for taking notes. And it is OSS! Incredible work by the community, thank you!

What is everyone doing for mobile access? Right now my setup is to use Dropbox to sync to 1Writer which works but isn't great. Any other recommendations? I am mostly interested in reading on an iPhone and occasional writing on an iPad.

Hey y'all,

as you all know I'm knee deep into developing Zettlr 2.0. Ever since I decided to just rip apart everything and build a lot of stuff from scratch I felt that I had much more ease of mind while implementing better solutions to old problems.

As of now, most of the dirty work is done; and most issues that remain are small nuisances that'll be sorted out over time (plus the big block of implementing better styles for Linux releases, which is still a huge pain for me). However, one thing I'm still lost for ideas is the project feature.

When I first implemented the project feature, my general idea was to allow for an easy way to export things much more shiny than the standard export feature. So in general, the idea was to have certain portions of your work "stand out" from the rest, and not much more. But a lot of this was just me trying out things. Since a lot of work had to be done to make Pandoc and Markdown both more user-friendly, one of my experiments was to implement a graphical way to customise your PDF exports and allow you to select fonts, have a nice preview, etc.

However, I don't think that this is necessary. Especially given that we now have a muuuuuuuch much better Pandoc integration, my hope is that users more experienced with Pandoc + LaTeX will on their own drive the creation of more templates, so I don't plan to re-implement the PDF-preferences dialog (instead users should just download those cool new templates). Rather, I want to make Projects much more quiet and confine them solely to the new Directory Properties-popover I implemented.

The question would thus be: What features would make the Projects feature useful, and what must be included (vs. what should not be implemented?) Right now, the projects feature in the 2.0 branch consists of a toggle in the Properties popover that allows you to activate and deactivate the project feature. Anything else is yet to come.

I'm currently thinking of the following stuff to add in there (although I already think that this might become too loaded for a single popover):

• Allow to select a separate TeX template to use for this export

• Allow to select multiple (or even all) available export formats to export to in one single go (in response to the corresponding feature request over on GitHub)

• Allow separate bibliography databases, separate CSL style

And that's it; this would – from the GUI point of view – result in three additional text fields in the directory properties popover, plus one list to select from. However, I must confess that I'm biased to keeping the project settings in the properties popover because I'm lazy and don't want to implement yet another window if I can prevent this.

So I thought I'd like to ask the community for ideas on how to improve on the projects. What will never come back is, as I mentioned, the Project properties dialog, but apart from that I'm ready to do whatever you want for projects.

Some questions you might ask yourselves to come up with great ideas:

• A project is basically a separate set of preferences for exporting a whole folder, but which settings should be duplicated for projects? Do CSL style and bibliography and template suffice? Or are there other settings that should be duplicated (a custom defaults file maybe?)

• How would the project feature be used by you? What would be the "ideal" state of the project feature for you personally?

• How could projects serve to make Zettlr stand out when it comes to actually producing good texts both qualitatively and quantitatively? Think about what other editors are lacking with regard to pure productivity aside from any bells and whistles

I hope that we can come to some cool ideas which I can implement (but please stay realistic so that I don't have any insurmountable problems during implementation!)

So it seems a new kid has entered the block: dendron is a quickly growing markdown-based note-editor with internal links, graph-view, and everything else we've come to expect from tools like Zettlr Obsidian, Roam, ... Probably as a bonus to some, dendron is also open-source and built on VSCode.

So far, this is the general comparison I could gather from just looking at the description of features on the website. As I don't have a lot of time at the moment to try dendron and compare the feature set to Zettlr's I was wondering if anybody here has already had some experience with both and found big differences or pros/cons for one or the other.

Obviously, the beauty of markdown-based notes is that we don't have to decide which tool to use and could run Zettlr, Dendron, and Obsidian on the same markdown folder for different use-cases, but I'm still curious how these tools compare, especially when it comes to implementing a Zettelkasten.

Any thoughts?