Jimmy: moving notes out of closed apps and into Markdown

Why note exports need a converter at all

Jimmy's one-line pitch is that it frees your notes by converting them to Markdown, and the use cases section explains why that matters in four lines.

The first is migrating between note apps, with the note that the output is compatible with Joplin, Obsidian and more. The second is saving notes in a future-proof, human-readable format. The third is preparing notes for processing in a LLM. The fourth is converting folders of office documents and PDFs recursively to Markdown.

Those four use cases describe three different users, and it is worth separating them because they want different things. The person leaving Evernote or Bear or Google Keep wants their content out before they lose access to the app. The person with a decade of archived documents wants searchable text instead of a folder of binary files. The person feeding notes into a model wants plain text with predictable structure and no proprietary markup in the way.

The tool is written in Python, but the README makes a point of how it is meant to be used: it is standalone, with no Docker, Python or Node.js installation required. The download links at the top of the README are prebuilt binaries for Linux, Windows and macOS, with the macOS one named for the arm64 architecture. The `pyproject.toml` in the repository still declares the Python package, so both routes exist, and the release binaries are the path most people should take.

The project is GPL-3.0 licensed, and the package metadata records `GPL-3.0-only` with the licence file in the package. The homepage is marph91.github.io/jimmy, and the documentation is built with MkDocs.

Two interfaces, and the TUI is the beta one

Jimmy provides two interfaces, and the README is direct about their relative maturity.

The Command Line Interface can be used for scripting and provides the full set of features. The Terminal User Interface can be used to do the conversion interactively, but currently it provides only a feature subset and is still in beta.

That split dictates how you would use it. Anything scripted, anything scheduled, anything processing a large export belongs on the CLI, because the full feature set is there. The TUI is for a person sitting in front of a terminal who wants to walk through a conversion and see what happens, and it is built on `textual` and `textual-fspicker` according to the dependency list, which is the Python library for rich terminal applications with a file picker.

The README shows the Linux command names, and the same binary names differ per platform, with the downloads for Linux, Windows and macOS named `jimmy-linux`, `jimmy-windows.exe` and `jimmy-darwin-arm64`.

# do the conversion using an interactive TUI
jimmy-linux tui

# convert a single file supported by pandoc
jimmy-linux cli libre_office_document.odt

# convert all files in a folder
jimmy-linux cli path/to/folder

# convert a Google Keep export
jimmy-linux cli takeout-20240401T160516Z-001.zip --format google_keep

The four examples show the shape of the CLI. A subcommand of `tui` or `cli` comes first, then the path or the archive. A single file is converted by giving the path. A folder is converted by giving the directory, and the use cases list says folders of office documents and PDFs are converted recursively. An export archive needs the format spelled out, as the Google Keep example does with `--format google_keep`.

The format flag is the general case. When the input is a file that a general tool can read, such as a LibreOffice document, the tool figures it out. When the input is a proprietary export bundle, you tell it which format it is.

The supported app list, and the cost of a per-format handler

The README devotes most of its length to a list of supported applications, each with a link to a documentation page describing that format in detail. The alphabetical run through the list covers Anki, Anytype, Bear, Cacher, CherryTree, Clipto, ColorNote, Day One, Diaro, Drafts, Dynalist, Evernote, Facebook, FuseBase and Nimbus Note, then Google Docs, Google Keep, Joplin and jrnl, with the topic tags naming further supported apps including Notion, Obsidian, OneNote, Signal, SimpleNote, Standard Notes, Synology, Telegram, TextBundle, TiddlyWiki and Zoho.

Each entry has its own format page, and that is the structural point. A converter for a proprietary app cannot be generic, because the export layout is specific to that app, so every supported app means a handler written for it. The consequence for a user is that the quality of the conversion differs per app, and the only way to know how good a particular migration will be is to read that app's format page and try a sample.

The dependencies show how the different categories are handled. `pypandoc` and `pyparsing` cover the office-document and markup side, `pdf-oxide` covers PDF text extraction, `beautifulsoup4` handles HTML sources, `python-frontmatter` and `pyyaml` write the front matter, and `markdown` is in the list for the output side. `puremagic` is there for file type detection, which is what lets `jimmy-linux cli libre_office_document.odt` work without a format flag, and `platformdirs` handles the per-platform data directories the app stores things in.

Three dependencies stand out as more specific. `anyblock-exporter` is pinned to a git commit, and it is a direct URL to a fork of an AnyBlock to Markdown exporter, which is how the Anytype format is handled. `pycrdt` is a CRDT implementation, which is what a collaborative editor's export format needs, and `signal-export` at 3.9.3 handles the Signal format. `cryptography` at 50.0.1 is pinned exactly, which is what you would expect for a tool that has to open encrypted export archives.

The output: Markdown with front matter, and what survives

The features list describes the output as Markdown plus front matter output, and expands on what that buys you. It is compatible with any text editor, it can be imported to Joplin, Obsidian and similar, and it preserves resources, tags and note links when possible.

The phrase when possible is doing the honest work in that list, and it is the single most important thing to understand before you point this at an archive of your notes. Tags, links between notes and embedded resources are the parts of a notes app that have no clean equivalent in plain Markdown, so a converter can only do its best with them, and the result depends on the source format.

The stated feature set also includes that the tool is offline, open source and cross-platform, and it makes one negative claim that is worth repeating because it is unusual to see it stated plainly: no AI is used during conversion.

That last point interacts directly with the third use case. If the plan is to prepare notes for processing in a model, then the conversion step being deterministic is a feature, because the transformation from the source app's layout to Markdown is reproducible and you can inspect exactly what the model will see, rather than a second lossy transformation happening inside the tool. The topic tags include `pandoc`, which is also why the `pypandoc` dependency is there, since Pandoc is the tool that handles the general markup and office document conversions.

The other structural point is that the output is files. A folder of Markdown files with front matter is something you can put in Git, grep, diff and script, and it does not depend on any particular application to remain readable, which is the whole argument for doing the conversion in the first place.

Where Jimmy is the wrong tool

The first wrong-tool case is a sync service rather than an export. Jimmy works on exports. The Google Keep example takes a `takeout` archive zip, and the documentation pages are per app and per export format. If your notes live in a service you cannot export, or if you want a continuously mirrored copy rather than a one-time migration, this is the wrong tool, because there is no watch mode or scheduled sync in the documented feature set.

The second is a demanding round trip. Jimmy converts out. It does not convert back in a way that restores an app's full data model, so a conversion that drops a note type, an attachment or a link structure is a one-way move for that content. Anyone planning a migration should treat the conversion as an export with a lossy tail and check the result against the original before deleting anything.

The third is interactive use on a large archive. The TUI covers a feature subset and is in beta, and it is an interactive interface, so a folder of thousands of documents belongs on the CLI where it can run unattended.

The fourth is a team that needs a supported tool. Jimmy is a single-maintainer open source project with no support contract, and the documentation is a MkDocs site that reflects whatever the maintainer last wrote.

The alternative worth naming is doing the conversion inside Pandoc directly, since Pandoc already handles the office-document and markup side and Jimmy itself depends on it for that work. The difference in approach is that Pandoc converts between markup formats and knows nothing about the export layout of Evernote, Google Keep or Bear, so those need a bespoke handler, which is exactly the layer Jimmy provides. For a folder of .docx files, Pandoc alone is the lighter answer. For a notes app export, it is not an option.

Maintenance, the release train and what is in the tree

The project is actively worked on. Version 1.1.30 was released on 2026-10-20, 1.1.29 on 2026-10-10 and 1.1.28 on 2026-07-25, and the last push to the default branch was on 2026-10-20. The repository is not archived, and the release cadence is close to monthly with patch releases in between, which is what you would expect from a tool whose value is in tracking export formats that change underneath it.

The version numbering is a plain 1.1.x, so the Python package can be installed with a simple requirement, and the packaged binaries are named per platform on the releases page.

The dependency pinning is strict, and it is strict for a reason. `beautifulsoup4` is at 4.15.0, `cryptography` at 50.0.1, `markdown` at 3.10.3, `pdf-oxide` at 0.3.78, `platformdirs` at 4.11.8, `puremagic` at 2.2.0, `pycrdt` at 0.14.5, `pypandoc` at 1.17, `pyparsing` at 3.3.2, `python-frontmatter` at 1.3.0, `pyyaml` at 6.0.3, `rich` at 15.0.0, `signal-export` at 3.9.3, `textual` at 8.2.8 and `textual-fspicker` at 1.0.1. Exact pins on a library with this many formats is a deliberate choice, and it means a bug fix upstream arrives when the maintainer bumps the pin rather than on its own.

The Python floor is 3.14, and the classifiers name Python 3.14, which is a high bar for a tool people might want to run on an older machine. That is one of the reasons the standalone binaries matter: they are built and shipped so that the Python version on your machine is irrelevant.

The rest of the tree describes the workflow. There is a `src/` directory, a `test/` directory, `docs/` for the MkDocs site with a `mkdocs.yml`, a `download_binaries.py` script and a `jimmy.spec` file, which is the PyInstaller spec used to produce the standalone binaries. There is a `skills.md`, a `lint.sh` script, a `uv.lock` for dependency locking, and a `.gitmodules`, which is consistent with a project that vendors something as part of the build.

The licence is GPL-3.0-only, and the repository carries a `license` file. For a tool you run on your own notes that is a reasonable choice, and the copyleft matters mainly for anyone who wants to redistribute a modified build. This is a description of the published terms, not legal advice.

Editorial conclusion

Adopt Jimmy when you are leaving a note-taking app, or when you have a folder of office documents and PDFs that you want as plain Markdown files you can grep, diff and feed to something else, because the output is human-readable and free of a runtime dependency on the original app. Do not adopt it expecting a lossless round trip, since resources, tags and note links are preserved only when possible, and do not treat the terminal interface as production ready, since the README calls it beta and it covers only a feature subset. Before you run it on a real archive, convert a small sample first and compare the result by hand, check that the source app's export format matches the handler you need, and note that the packaged binaries are what most users should install rather than the Python package.

Frequently asked questions

Official sources

1. License: GPL-3.0
2. marph91/jimmy on GitHub
3. Project website
4. README
5. Releases