novelWriter: a plain text editor that stores a novel as files you can read without the app

The storage decision is the whole design

novelWriter describes itself as a plain text editor designed for writing novels assembled from many smaller text documents. That phrase is doing more work than it looks. Most novel software stores a project in a database, an archive or a structured XML file, and if the vendor disappears or you change tools, the work needs converting. This one uses human readable text files as storage, and the README names two reasons: robustness, and suitability for version control software and file synchronisation tools.

That decision has visible consequences in the repository. The tree contains `novelWriter.py` as the launcher, a `novelwriter/` package for the application code, a `sample/` directory, and `uv.lock` rather than a requirements file, which says the dependency set is resolved through uv. The `pyproject.toml` names `setuptools>=77.0.3` as the build requirement and declares the project name as `novelWriter` with a capital W.

The editor is written in Python with Qt6 through the PyQt6 bindings, released for Linux, Windows and macOS. It also carries a `pyenchant` dependency, which is the spell checking library that sits behind the Qt spell checking add-on, and a macOS specific `pyobjc-framework-Cocoa` binding. Python 3.11 is the floor.

The last push was on 2026-09-22, and version 26.2 was released on 2026-09-05, with 26.2rc1 and 26.2b2 preceding it. The calendar versioning scheme here is worth noting if you script against releases: the tag is a year and a sequence number rather than a semver triple.

A minimal markup syntax and a separate metadata syntax

The formatting syntax is described as minimal and inspired by Markdown, with the addition of a meta data syntax covering comments, synopsis and cross-referencing. The README does not enumerate the commands, and that omission is deliberate on the project's part: the documentation site carries the syntax reference, and the README's job is to explain what the program is and where the manuals live.

The split between formatting and metadata is the interesting part of the design. Formatting covers emphasis, headings and the like. Metadata covers things that are not part of the prose at all: a comment for yourself, a synopsis line for a scene, a reference to a character or a location. A writer planning a long book needs those to be distinguishable from the text, and being able to filter them out is what lets the plain text storage model work. If you exported a chapter to send to a beta reader, you would want the synopsis lines gone.

Because the files are plain text, the same mechanism means an outside tool can work on the project. Searching for a character name across every file, running a word count over a chapter, or diffing two commits in git all work without any export step from the application.

What the packaging metadata actually declares

The `pyproject.toml` is the most precise description of the project in the repository, and it says a little more than the README does about licensing.

[project]
name = "novelWriter"
description = "A plain text editor for planning and writing novels"
requires-python = ">=3.11"
dependencies = [
    "pyqt6>=6.4",
    "pyenchant>=3.3.0",
    "pyobjc-framework-Cocoa; sys_platform == 'darwin'",
]

Two things stand out. First, the classifiers run from Python 3.11 through 3.14 and mark the development status as Production/Stable, with the operating system listed as independent and the intended audience as end users on the desktop.

Second, and worth reading twice, the license field is `GPL-3.0-or-later AND Apache-2.0 AND CC-BY-4.0 AND ISC`, while the README states that novelWriter is licensed under GPLv3 and points at the GNU license. These are not necessarily in conflict. The README explains that bundled assets and their licenses are listed separately in the Credits document, so the compound expression most likely covers the code plus differently licensed bundled material, with CC-BY-4.0 covering documentation or data and ISC covering something small. If you need certainty about what applies to a specific asset, CREDITS.md at the repository root is the document that resolves it, and the license field alone will not.

The dependency groups are organised by purpose rather than dumped together: `build` holds pyyaml, `docs` the Sphinx toolchain with the book theme and translation support, `test` coverage with pytest-qt and pytest-timeout, and `lint` pyright and ruff.

Release branches, contributions, and an unusual content policy

The README states the branching model plainly: new features and pre-releases are made on the `main` branch, while full releases are made from the `release` branch. If you are submitting a fix to a current release, including documentation changes, it has to go to `release`. That is a sensible arrangement for an application people install rather than one they vendor, and it means `main` can carry a 26.3 development cycle without destabilising what is already out.

The contribution guidance is unusually specific and worth reading before opening a pull request. Feature pull requests should be discussed with the maintainer first, either through the issue tracker or a discussion. Pull requests that reformat or rewrite existing code are discouraged unless there is a very good reason. Contributions about packaging and installing are welcomed but should start as an issue or a discussion. And the README asks contributors not to submit AI generated content, which is a stated project policy about contributions rather than anything about how you may use the resulting editor.

Translations run through Crowdin, with a dedicated issue thread for questions, and the repository links to the Crowdin project page directly. The project also credits free code signing on Windows from SignPath.io with a certificate from the SignPath Foundation, and package hosting from Cloudsmith. Those two arrangements explain why the tree contains `setup/` with packaging assets and installer material.

Against Scrivener, Bibisco and the ordinary text editor

Scrivener is the comparison everyone makes, and the difference comes down to what a project is. Scrivener stores a project as a binary document with internal structure, which buys a corkboard, outliner metadata and compile targets that plain files cannot express. novelWriter deliberately gives that up: a project is a directory of text files, and the structure comes from the syntax inside them and the folder layout rather than from an application database.

What you get in exchange is durability across tools. If you stop liking novelWriter, the work is still readable text. If you want a different editor for a chapter, nothing blocks you. If you want to put the project in git, the diffs mean something.

Bibisco is closer in spirit, being a plain text based writing application with a character and scene model, and the comparison comes down to how much structure each insists on. Related searches around this project pair it with Bibisco and with Scrivener directly, which suggests readers are trying to work out the same thing.

The honest limitation is scope. There is no mobile application, no web version and no collaboration feature in this repository, so a novel has to live on one machine or be synchronised as files. That is a real constraint for a writer who drafts on a phone, and the plain text storage does not fix it on its own.

Editorial conclusion

novelWriter suits a writer with one long project who wants the safety of structure around chapters, scenes and notes, and who does not mind installing a Python application rather than downloading an installer. It is a poor fit for a writer working across several novels in one window, or for anyone who wants cloud collaboration, since there is no account system and no sharing story here. Install from PyPI, read the documentation on docs.novelwriter.io for the syntax reference, and test the plain text storage assumption early by opening a project directory in a normal editor.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. Project website
3. README
4. Releases
5. saga-soft/novelWriter on GitHub