imessage-exporter: Export iMessage History to TXT or HTML Without Uploading It

The problem imessage-exporter solves for Mac users

Apple's Messages app keeps conversation history in a SQLite database that is not meant to be read by hand. The README describes the project's aim as providing "the most comprehensive and accurate representation of iMessage data available", and the binary delivers that by writing conversations to txt or html files. The audience is narrow and specific: people who want a local archive of their own messages, people migrating history between devices and platforms, and anyone who needs message records for a data retention policy or a legal request. The README lists those use cases directly, alongside preserving images, videos and audio from conversations. The project is a Rust workspace with two members: imessage-database, a library that models iMessage data as cross-platform structures, and imessage-exporter, the binary built on top of it. That split matters. The library is the interesting artifact for other developers; the binary is what a normal user runs.

How the export pipeline works: SQLite in, txt or HTML out

The binary is read-only against the Messages database. It parses the SQLite schema, reconstructs messages, and serialises them into one of two output formats. The README frames the library as exposing iMessage information as "native, cross-platform data structures", which is why the same binary can run on macOS, Linux and Windows even though the database itself is created by Apple's software. The feature list is long and worth reading as a scope statement rather than a checklist: iMessage, RCS, SMS and MMS; multi-part messages; replies and threads; formatted text; attachments; expressives; tapbacks; stickers; Apple Pay; group chats; Digital Touch; URL previews; audio messages; app integrations; edited messages; business messages; handwritten messages. The README claims support for every iMessage feature as of macOS Golden Gate 27.0 (26A428) and iOS 27.0 (24A437). Treat that as the version the maintainer targeted, not a guarantee about your own database. The repository also credits the reverse-engineering work behind the format handling: SQLiteFlow for exploring the database, Xplist for the payload_data plist format, and the GNU Project and Archive.org for source used to reverse engineer typedstream. That is a fair summary of how much of this tool exists because Apple documents none of it.

Installing imessage-exporter and running a first export

The binary's installation instructions live in imessage-exporter/README.md, and the crate is published, so the usual route is Cargo. If you do not have a Rust toolchain, install one first; the project does not ship a separate installer.

cargo install imessage-exporter

After that, the binary is on your PATH. The README does not spell out a full command line in the top-level file, so check the binary's own README for the exact flags before you run anything against a real database. Once you have them, a typical invocation points the tool at the Messages database and chooses an output format, and the result is a directory of txt or html files plus the attachment media. The project also exposes a diagnostics mode, described in the README as finding problems with the iMessage database, which is a reasonable first run if you want to know whether the database is readable before committing to a full export. Two practical notes before you start: the Messages database is normally protected by macOS, so a terminal process may need Full Disk Access to open it, and the README lists the supported feature set as version-specific, so a very old or very new macOS release is the case most likely to produce surprises.

Where imessage-exporter falls short

The output formats are txt and html, and that is the whole list in the README. If you need a PDF, this is not the tool. The search questions around PDF exports have no answer here. The other limitation is structural rather than a bug: the tool reads a database whose schema Apple controls and does not document. The README's own credits make this explicit, with typedstream reverse engineering sourced from archived Darwin code. When Apple changes how messages are stored, the parser has to catch up. The last push to the repository was on 2026-09-20 and the most recent release, 4.3.0 (Shining Willow), was published on 2026-09-15, so the project is being kept current, but that cadence is also the measure of how much reverse-engineering work the format requires. Finally, the README does not document rollback or an undo path for an export, and it does not describe a verification step for the resulting archive. If you are exporting for legal or compliance reasons, that gap is on you to close.

imessage-exporter compared with a general SQLite viewer

The obvious alternative is opening the Messages database directly in a SQLite browser and writing your own queries. That approach gives you total control and no dependency on a third-party parser, and tools like SQLiteFlow are exactly how the maintainer explored the schema in the first place. The difference is in what you get for free. A raw query returns rows; it does not reassemble multi-part messages, resolve tapbacks, decode typedstream payloads, pull attachments out of their blob storage, or render formatted text. imessage-exporter exists to do that reassembly, and the README's feature list is essentially the inventory of problems a hand-written query would leave to you. The trade-off runs the other way too: with direct SQL you can extract a custom projection, filter by an arbitrary predicate, or join against your own tables, and no export tool will match that flexibility. Pick the CLI when you want a faithful archive; pick SQL when you want a specific answer.

Maintenance, licence and what an upgrade costs you

The repository is not archived, and the last push was on 2026-09-20, two days before this writing, with releases in September, June and May of 2026. That is a project under current maintenance. The licence is GPL-3.0, which is the part to think about before building on the library rather than running the binary. Running the CLI to export your own messages is the straightforward case. Linking imessage_database into a proprietary application is where the copyleft terms become a question for your own counsel, and the repository does not offer a dual-licence or commercial option in the available documentation. Upgrades are Cargo upgrades, and the workspace Cargo.toml sets lto = true, codegen-units = 1 and panic = "abort" for release builds, which means a from-source build is slow and a panic terminates rather than unwinding. If you install from crates.io you skip that build cost, but you also take whatever the published version supports. The README ties feature coverage to specific macOS and iOS releases, so re-check that statement after a major OS upgrade rather than assuming the previous export still reflects reality.

Editorial conclusion

Adopt imessage-exporter if you need a local, scriptable copy of your Messages history in txt or HTML and you are comfortable installing a Rust binary. Do not adopt it if you expect a PDF report, a GUI, or a hosted service, because the binary only writes txt and HTML. Before trusting an archive, verify on your own machine which of the listed features your database actually contains, and check whether your macOS version still stores data where the tool looks. The GPL-3.0 licence also matters if you plan to link the imessage_database library into a closed product.

Frequently asked questions

Official sources

1. Issues
2. License: GPL-3.0
3. README
4. ReagentX/imessage-exporter on GitHub
5. Releases