# Inlyne: a browserless Markdown and HTML viewer for quick local previews

> Inlyne is a Rust desktop viewer that opens Markdown files without launching a browser. It combines a limited HTML renderer, GPU-backed drawing, system theme detection, and automatic refresh, but it is not intended to reproduce a full browser.

**Inlyne-Project/inlyne** — a GPU powered yet browserless tool to view markdown files in the blink of an eye

- Repository: https://github.com/Inlyne-Project/inlyne
- Stars: 1,349 · Forks: 51
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/inlyne-project-inlyne

## Why Inlyne avoids the browser for local Markdown

Inlyne addresses a narrow but common desktop problem: opening a Markdown file quickly while working in a terminal, editor, or Vim-oriented environment. A browser can render the same file, and the README explicitly acknowledges that a browser or Visual Studio Code may produce a more accurate result. Inlyne instead focuses on a small native application for viewing one document at a time.

The project is written primarily in Rust and uses WGPU, Winit, Lyon, and Glyphon, according to `Cargo.toml`. WGPU supplies the graphics API abstraction, Winit handles the native window, and Lyon participates in 2D shape layout. Glyphon is identified as the GPU text-rendering dependency. Based on those components, Inlyne presents itself as a custom rendering stack rather than an embedded browser or an Electron shell.

That boundary matters. Inlyne does not attempt to be a general web runtime. Markdown is first converted to HTML with `comrak`, and Inlyne then parses that output with `html5ever`. The resulting document is drawn through Inlyne's native renderer. This architecture reduces the amount of application infrastructure involved in a local preview, but it also means that browser behavior is available only where Inlyne has implemented a compatible rendering path.

## How Inlyne turns Markdown into a native window

The documented data flow starts with a Markdown input file. Inlyne converts the Markdown to HTML using `comrak`, including any supported HTML written directly inside the Markdown. It then parses that HTML with `html5ever`. The repository dependencies also include image decoding through `image`, frontmatter value handling through `html-escape`, and text caching through `fxhash`.

Rendering is handled by a native graphics stack rather than Chromium, WebKit, or another browser engine. The project describes WGPU as the reason rendering can take place on the GPU where possible. This wording is appropriately qualified. GPU usage does not mean that every operation is graphical or that application startup and Markdown parsing disappear from the CPU. It describes how the presentation layer delegates supported drawing work.

Inlyne also watches the displayed Markdown file for write modifications. When the file changes, the viewer refreshes the document and retains the reading position where the user left it. The README calls this “Live Code Change” and presents it as a core feature. That is more useful than merely reopening the file: a documentation author can edit the source and inspect the result without manually managing a browser reload.

System color-scheme detection comes from the `dark-light` crate. Configuration is stored in TOML, while directory resolution uses the `dirs` crate. Those choices connect document rendering to the host operating system's theme and configuration conventions.

## Running the first Inlyne preview

The README provides a direct invocation for viewing a Markdown file and selecting its theme. From a directory containing the file, run this command:

```bash
inlyne view README.md --theme dark/light
```

This is the documented quick-start shape rather than an executable installation recipe. It opens `README.md`, with the command accepting either `dark` or `light` as the stated theme value. Users should see the rendered document in a native Inlyne window. If the window remains open, subsequent writes to that Markdown file should trigger an automatic refresh.

The README says packages are available from several repositories and links to Repology for packaging status, but it does not provide a platform-specific package-manager command. It also does not give a `cargo install` command. Those omissions prevent a precise installation command from being reproduced here.

For a source build, the README requires `cargo` with a somewhat recent Rust toolchain, a C compiler, and Linux development libraries for `fontconfig`, `xkbcommon`, and `wayland` when the Wayland feature is enabled. It gives `gcc` as the Ubuntu example for the C compiler and names the corresponding development packages. `Cargo.toml` states a minimum Rust version of `1.88.0` and defaults to both the `wayland` and `x11` features.

## Inlyne configuration and platform-specific prerequisites

Persistent command-line options belong in `inlyne.toml`, placed inside an `inlyne` directory under the operating system's default configuration location. The README gives three concrete paths:

```text
/home/alice/.config/inlyne/inlyne.toml
```

This is the Linux path, shown with the README's example user name. The README also gives the following Windows path:

```text
C:\Users\Alice\AppData\Roaming\inlyne\inlyne.toml
```

On macOS, the documented location is:

```text
/Users/Alice/Library/Application Support/inlyne/inlyne.toml
```

The repository includes `inlyne.default.toml` as the example configuration file. This is the first file to inspect when deciding whether Inlyne can match a local documentation workflow. It is more reliable than guessing option names because the README does not reproduce the configuration keys contained in that file.

On Linux, the default Cargo features include both Wayland and X11. Building with Wayland support therefore involves `fontconfig`, `xkbcommon`, and Wayland development libraries according to the README. Platform support beyond those build requirements is not documented in the README. The manifest does confirm the `x11` and `wayland` features, but it does not state supported operating-system versions.

## Supported Markdown and the deliberate HTML ceiling

Inlyne covers the structures commonly found in project documentation. The README lists tables, sized images, syntax-highlighted code blocks, lists, links, task lists, hideable sections, alignment, block quotes, and limited text effects. Code highlighting uses the `syntect` crate listed in `Cargo.toml`. This feature set makes Inlyne most relevant for README files, design notes, and repository documentation maintained alongside source code.

Raw HTML support is the important limitation. The project converts Markdown to HTML, then renders only enough HTML for common cases. The README specifically mentions elements such as `<br>`, `<h1>`, and `<img>`, but excludes broad CSS support and interactive constructs such as forms and buttons. The FAQ describes the intended scope as rendering 95% of Markdown files, yet that percentage is the project's own expectation rather than a compatibility result accompanied by test details.

This makes Inlyne the wrong tool for documents that depend on scripts, form controls, complicated layout, or browser-specific HTML behavior. The README does not document scripting support, a comprehensive CSS parser, or browser automation features. A page that looks acceptable in a browser may therefore appear incomplete in Inlyne. The live reload behavior does not address that compatibility gap, because it changes when the document reloads, not which HTML features the renderer understands.

A browser or Visual Studio Code is the clearest alternative. Both can interpret a wider range of web content and, as the README acknowledges, may render it more accurately. Inlyne's difference is operational: it is a focused native window for quickly previewing one file, whereas those alternatives provide broader editing and web-platform environments.

## Release activity, licensing, and the native viewer trade-off

The repository is not archived. Its last push was on 2026-08-06, and releases `v0.5.3`, `v0.5.2`, and `v0.5.1` were published on 2026-08-06, 2026-05-19, and 2026-05-13 respectively. These dates indicate recent repository activity, but the README does not define a release-support policy or long-term compatibility promise for the renderer.

Upgrade cost comes partly from the native dependency stack. A source build needs Rust tooling and a C compiler. Linux builds can also require development libraries for font configuration, input handling, and Wayland. Users who rely on embedded HTML or detailed styling may need to check `CHANGELOG.md` after upgrading because the project does not publish a compatibility matrix in the README.

The crate and repository use the MIT License. The README says that code in the repository may be copied under that license. This is a licensing summary rather than legal advice, and it does not replace examination of the repository's `LICENSE` file for the complete terms.

Inlyne ultimately trades breadth for a direct viewing path. It avoids a browser process and provides GPU-backed native rendering, live updates, and reading-position preservation. In return, complex HTML and browser-oriented behavior sit outside its documented scope.

## Conclusion

Inlyne suits developers who want a fast local preview of repository Markdown without keeping a browser open. It is a poor fit for interactive documents, complex HTML, or complete CSS fidelity. Verify first that the required HTML subset covers your documents, that your platform has the necessary build libraries, and that the documented configuration location matches your workflow.

## FAQ

### How do I install Inlyne on my operating system?

The README links to Repology for available packages, but it gives no platform-specific installation command. It also omits a `cargo install` command, although it documents building from source.

### How do I open a Markdown file and choose a theme in Inlyne?

The documented command is `inlyne view README.md --theme dark/light`. Replace the sample path with the Markdown file you want to view and select the stated `dark` or `light` theme value.

### Does Inlyne support interactive HTML and complete CSS?

No. The README limits raw HTML support to common elements and explicitly places forms, buttons, and every CSS style outside the intended scope. Use a browser or Visual Studio Code when full web rendering is required.

### What happens when I edit a Markdown file in Inlyne?

Inlyne monitors the displayed file for write modifications and automatically refreshes it. The README states that the viewer keeps the reading position where the user left it.

### Where can I configure Inlyne permanently?

Place `inlyne.toml` in an `inlyne` directory under the operating system's default configuration directory. The repository also contains `inlyne.default.toml` as an example.

## Sources

- [Inlyne-Project/inlyne on GitHub](https://github.com/Inlyne-Project/inlyne)
- [Issues](https://github.com/Inlyne-Project/inlyne/issues)
- [License: MIT](https://github.com/Inlyne-Project/inlyne/blob/main/LICENSE)
- [README](https://github.com/Inlyne-Project/inlyne/blob/main/README.md)
- [Releases](https://github.com/Inlyne-Project/inlyne/releases)

---

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