# Ferrite Editor for Markdown, JSON, YAML, and TOML

> Ferrite is a Rust and egui desktop editor for Markdown and structured text files. It adds rendered editing, split view, exports, and code-block execution, while macOS packaging remains experimental.

**OlaProeis/Ferrite** — A fast, lightweight text editor for Markdown, JSON, YAML, and TOML files. Built with Rust and egui for a native, responsive experience.

- Repository: https://github.com/OlaProeis/Ferrite
- Stars: 1,890 · Forks: 102
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/olaproeis-ferrite

## Ferrite's Target Files and Users

Ferrite addresses the space between a plain text editor and a document-oriented writing application. It is built for people who edit Markdown, JSON, YAML, and TOML and want format-aware presentation without moving local files into a browser editor or general-purpose IDE. The README describes Ferrite as a native desktop application built with Rust and egui. Repository topics also identify Markdown editing, Mermaid, WYSIWYG, and structured data as parts of the project’s scope.

The likely audience consists of developers, technical writers, and other users who keep documentation or configuration in local files. JSON, YAML, and TOML require precise syntax, so a source editor remains necessary. Markdown presents a different requirement: authors often want a rendered representation while retaining control over the underlying text. Ferrite addresses both needs through source and rendered views.

Repository screenshots identify three working modes: Raw Editor, Split View, and Zen Mode. Raw Editor suits exact changes to structured files. Split View keeps source and rendered content visible together. Zen Mode provides a separate layout, although the README excerpt does not document its controls or persistence behavior. The distinctions matter because Ferrite is not simply converting every supported file into a visual document. The project retains a text-centered workflow and adds presentation features around it.

## Rust, egui, and Ferrite's Rendering Stack

Ferrite uses Rust for its application and GUI layer. `Cargo.toml` selects `egui` version `0.34` and `eframe` version `0.34`. Eframe is configured with `glow`, `accesskit`, `default_fonts`, `wayland`, and `x11`. Based on that feature selection, Ferrite uses the Glow renderer rather than eframe’s default renderer configuration. The dependency comment explains that Glow avoids a `wgpu-hal 29` and Windows `windows` crate duplication under MSVC. It also says the renderer choice should be revisited when the upstream egui ecosystem aligns.

The format stack uses `comrak` for Markdown and `serde_json`, `serde_yaml`, and `toml` for JSON, YAML, and TOML. Ferrite also depends on `syntect` for syntax presentation. The `two-face` dependency adds syntax definitions for languages including PowerShell and TypeScript. This gives the editor separate components for document rendering, structured-data handling, and text syntax presentation, although the public README does not expose enough implementation detail to describe the complete rendering pipeline.

Default Cargo features include `bundle-icon` and `high-perf-alloc`. The allocator feature enables `mimalloc` on Windows and `jemalloc` on Unix through `mimalloc` and `tikv-jemallocator`. The `Cargo.toml` comments associate this configuration with reduced heap fragmentation and lower memory use during long sessions. That is a project claim rather than a measured benchmark result.

Two optional features deserve scrutiny. `async-workers` adds `tokio` and `poll-promise` for background work associated with AI, SSH, and database operations. The `lsp` feature is present, but it currently contains no dependencies and a comment describes the Language Server Protocol work as deferred. The configuration therefore does not establish that diagnostics, hover, or go-to-definition are available in v0.3.0.

## Raw, Split, and Rendered Editing

Ferrite’s editing modes reflect different document needs. Raw Editor exposes the underlying text, which is important for JSON, YAML, and TOML because whitespace, quoting, and indentation can affect meaning. Split View places source and rendered output together, allowing an author to review presentation without losing sight of Markdown syntax. Zen Mode is shown in the repository screenshots, but the README does not specify which controls it hides or whether settings persist between sessions.

The v0.3.0 release notes add a rendered edit session and one-click WYSIWYG block switching. This extends the split workflow by allowing individual content blocks to switch between visual and source-oriented editing. The likely benefit is reduced friction when composing prose, especially in long Markdown documents. The tradeoff is source fidelity. The README does not document how whitespace, escaped characters, custom attributes, malformed Markdown, or partial block conversions are preserved. Teams that review Markdown through Git diffs should test those cases before treating WYSIWYG mode as the only editing interface.

Syntax presentation extends beyond Markdown. `two-face` supplies definitions for PowerShell, TypeScript, and other languages, which can improve the appearance of fenced code examples. This is separate from language intelligence. Ferrite’s `lsp` feature is empty, and its comment says the integration was deferred rather than completed. The README does not document active language-server diagnostics, hover text, or go-to-definition in the current release. Users who depend on those features should treat them as unverified.

## Installing and Launching Ferrite

The README states that Ferrite is developed and tested on Windows and Linux. macOS support is experimental. Windows releases from v0.2.6.1 onward are digitally signed with a certificate from SignPath Foundation. The README also advises downloading the latest signed release when an older Windows build triggers an antivirus warning.

For macOS, the README describes a Homebrew cask as the smoother installation route. The following commands add the Ferrite tap and install the cask.

```bash
brew tap olaproeis/ferrite
brew install --cask ferrite
```

Homebrew may avoid the quarantine friction associated with a direct GitHub download, but macOS support is still described as experimental. The README does not provide a command-line launch instruction for the installed cask, so users should launch Ferrite through the macOS application interface.

Direct release packages are also available for Apple Silicon and Intel. Files named `ferrite-macos-arm64.dmg`, `ferrite-macos-x64.dmg`, and their `.tar.gz` counterparts contain `Ferrite.app`. These builds are not signed with an Apple Developer ID and are not notarized. Gatekeeper may warn or block the first launch. If Ferrite has been copied to `/Applications`, the README gives this command for removing its quarantine attribute.

```bash
xattr -dr com.apple.quarantine /Applications/Ferrite.app
```

Users should substitute the real path if the application is stored elsewhere. The README also describes opening the app through Finder or Privacy & Security, but it warns that Finder’s workaround may not work in every macOS 15.x configuration.

Developers can build from the Rust repository. `Cargo.toml` specifies Rust `1.92`, and the repository includes `rust-toolchain.toml`. Its Makefile exposes these build and launch targets.

```bash
make build
make run
```

`make build` invokes `cargo build`. `make run` invokes `cargo run`, which launches the debug application. The README links to `docs/building.md` for additional source-build guidance, but it does not enumerate every native prerequisite.

A first practical session can start with `make run`, open an existing Markdown file, and compare Raw Editor with Split View. For structured files, open a JSON, YAML, or TOML document and verify indentation, quoting, and formatting after saving. These checks are important because the screenshots show editing modes but do not document file-open commands or keyboard shortcuts.

## Exports, Executable Blocks, and File Access

The v0.3.0 notes document PDF and themed HTML export. These features are useful when a Markdown document needs a distributable artifact while the source remains a local text file. The README does not document image handling, custom fonts, CSS coverage, print layouts, or whether embedded Mermaid diagrams are included in either format. Documents that depend on those elements require direct comparison between the source, rendered view, and exported output.

Executable code blocks are another feature with operational consequences. The README’s antivirus section says the Live Pipeline uses `cmd.exe /C` for shell commands on Windows. It does not document a sandbox, allowlist, timeout policy, or confirmation dialog. Code from an untrusted Markdown file should therefore not be run merely because it is open in the editor. The feature is intended for commands selected by the user, but the README provides no further execution controls.

Ferrite’s documented network behavior is narrow. The README says it does not access passwords or browser data, makes no unsolicited network connections, and accesses only files explicitly opened by the user. The manual `Check for Updates` button under Settings and About contacts the GitHub Releases API. These statements describe the intended application boundary. They do not amount to an independent audit of source code or dependencies.

## Ferrite Releases, Signing, and Source Maintenance

The repository is not archived. Its last push was on 2026-10-08. Recent releases include v0.3.0 on 2026-05-22, v0.2.9 on 2026-04-23, and v0.2.8 on 2026-04-15. Those dates show recent project activity, but they do not establish compatibility between every release or the completeness of every documented feature.

Platform-specific release engineering differs. Windows binaries have been signed since v0.2.6.1. macOS `Ferrite.app` packages remain unsigned and unnotarized because the README says paid Apple enrollment and CI wiring are still pending. Linux installation details are not described in the README excerpt, so Linux packagers should check the GitHub Releases page before assuming a particular package format.

Ferrite is distributed under the MIT license. That license identifier and its associated notice file should be retained when redistributing or incorporating the software as permitted by its terms. This is not legal advice.

Source checkouts also have an explicit maintenance workflow. The Makefile defines `make precommit`, which runs formatting, Clippy with warnings denied, tests, and a build.

```bash
make precommit
```

This target provides a concrete way to check a local revision. It does not replace release signing, cross-platform testing, or file-format round-trip testing. Contributors changing rendering or structured-file behavior should also run the repository’s test suite through the documented Make targets before reviewing diffs.

## Ferrite Against Plain Text Editors and General IDEs

A plain text editor keeps the document model direct: the file is text, and the editor leaves interpretation to other tools. Ferrite retains that source model but adds Markdown rendering, structured-format libraries, syntax presentation, export, and executable code blocks. The difference is architectural. A plain editor may be preferable when predictable byte-level editing and a large extension ecosystem matter more than rendered documents.

Ferrite offers a more focused workflow for technical authors. Split View connects source and rendering, WYSIWYG block switching can simplify prose editing, and PDF or themed HTML export can produce finished artifacts without a separate publishing step. General-purpose IDEs can provide deeper language tooling and integrations, but Ferrite does not clearly offer the same ecosystem.

The limitation is source-control discipline. Because Ferrite can render and edit content visually, users need to confirm that the raw file remains authoritative after block switching and export. The README does not document rollback, malformed-input recovery, or serialization guarantees for visual edits. Ferrite is the better fit for local Markdown and structured-text work that values document presentation. It is the weaker fit when guaranteed macOS signing, established extension support, or fully operational language-server features are prerequisites.

## Conclusion

Ferrite suits developers and technical writers who want a focused desktop editor for Markdown and structured text, particularly when rendered editing, split view, and local export matter. It is a weaker choice for users who require signed macOS distribution, a mature extension ecosystem, or documented language-server behavior. Before adopting it, verify the appropriate download for your platform, confirm the current status of `lsp`, and test representative files because WYSIWYG editing and executable code blocks require closer inspection than the README provides.

## FAQ

### What file formats does Ferrite support?

Ferrite is documented as an editor for Markdown, JSON, YAML, and TOML. It also includes syntax definitions for languages such as PowerShell and TypeScript through `two-face`.

### Is Ferrite available on macOS?

Yes, but the README describes macOS support as experimental. GitHub release builds contain an unsigned, unnotarized `Ferrite.app`, so Gatekeeper may warn or block the first launch.

### How do I build Ferrite from source?

The repository Makefile documents `make build` for a debug build and `make run` to launch it through Cargo. `Cargo.toml` specifies Rust version `1.92`.

## Sources

- [Issues](https://github.com/OlaProeis/Ferrite/issues)
- [License: MIT](https://github.com/OlaProeis/Ferrite/blob/master/LICENSE)
- [OlaProeis/Ferrite on GitHub](https://github.com/OlaProeis/Ferrite)
- [README](https://github.com/OlaProeis/Ferrite/blob/master/README.md)
- [Releases](https://github.com/OlaProeis/Ferrite/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/olaproeis-ferrite