TeXlyre: LaTeX and Typst compiled in the browser, with Yjs and WebRTC

A LaTeX and Typst editor that compiles without a server

TeXlyre is a web editor for LaTeX and Typst, and its defining technical decision is that the compilation happens in the browser. The project integrates the SwiftLaTeX engine, based on TeX Live 2020, and the BusyTeX engine, based on TeX Live 2026, as WASM engines, which the documentation describes as providing in-browser LaTeX compilation without server dependencies. The current engine support covers pdfTeX, XeTeX and LuaTeX.

For Typst the same principle applies through typst.ts, which provides in-browser Typst compilation without server dependencies. PDF, SVG and canvas compilation are supported there.

The second defining decision is the data model. The platform uses Yjs CRDTs for conflict-free synchronization, so changes from multiple users are merged without conflicts, and communication happens through WebRTC peer-to-peer connections, which the documentation presents as low latency collaboration without requiring a central server. The result is described as a local-first real-time platform with offline editing capabilities, built with React, TypeScript and Yjs.

The audience is students, research groups and small writing teams who share LaTeX or Typst projects. Those users get an editor that opens a project, compiles it and keeps working when the network is gone, and they get share links and live cursors without an account system in the middle.

What WebRTC changes about a shared document

Peer-to-peer transport is not a detail here, it is the shape of the product. With WebRTC, the collaborators are the clients, and each participant holds the document state locally through the CRDT. The document lives on the machine of every person editing it and in the browser's local storage when they are offline.

The visible effects are the cursor and selection awareness across all connected clients, and the offline badge in the project's own status indicator, which flips between online and offline. The CRDT is what makes that work: because the merge is commutative, two people editing the same paragraph while disconnected do not produce a conflict to resolve later, they produce two versions that merge when the connection returns.

Around that core the project layers the collaborative furniture. There is an integrated chat system so collaborators can talk inside the editing environment, and a file explorer with drag-and-drop for LaTeX sources, Typst sources, images and data files. Document linking creates connections between collaborative documents and static files, and FilePizza integration provides peer-to-peer file sharing for large transfers without intermediary servers.

The flip side of pure peer-to-peer is worth stating plainly. There is no central server to hold the authoritative copy, which is the point, but that also means the joining mechanism and any future server component are part of the project's own design decisions rather than something you can point at a hosted deployment for. The repository includes plugins.config.js and a plugins directory, so plugin behaviour is configurable, and the self hosting topic on the repository indicates deployments run this stack themselves.

SyncTeX works only with the BusyTeX engines

SyncTeX, the source mapping between LaTeX source and the compiled PDF, is supported only with the BusyTeX engines. Clicking the SyncTeX button in the PDF viewer highlights the corresponding region in the output, and reverse SyncTeX is supported too, letting you jump from a location in the compiled PDF back to the matching line in the source.

That restriction is the sharpest engine level constraint in the project, and it interacts with the 0.13 release line in a way that matters in practice. If a team standardises on pdfTeX and expects forward and reverse SyncTeX to work, the engine choice has to move to BusyTeX, which means giving up the TeX Live 2020 base that SwiftLaTeX carries.

The editor does compensate elsewhere. Real-time syntax highlighting and error detection are supported, with an integrated PDF viewer offering zoom, navigation and side-by-side editing, and the error panel shows parse output as compilation proceeds. That combination, live errors plus a side-by-side PDF, is the everyday substitute for SyncTeX on engines where SyncTeX is unavailable.

Typst SVG and HTML output are flagged as experimental

Typst compilation through typst.ts supports PDF, SVG and canvas output, but the documentation is explicit that SVG and HTML compilation are experimental and are not guaranteed to work as expected at the time being. HTML is listed in the same sentence even though the supported list names PDF, SVG and canvas, which reads as a reminder that the Typst side of the project is the less settled half of the two language support.

For LaTeX the engine situation is more settled, with pdfTeX, XeTeX and LuaTeX all in the supported list, though each of them comes from the two WASM builds with the TeX Live version differences described above.

There is also a mismatch worth noting between what the two language paths provide in the browser. The Typst path has no equivalent of the SyncTeX source mapping, and the Typst side of the tool chain leans on separate helper projects, typst.ts for compilation and typst-wordometer for word counts, while LaTeX has the SwiftLaTeX and BusyTeX engines plus TeXcount. Anyone planning a mixed LaTeX and Typst workflow should expect the LaTeX path to be the more complete one.

Word counts and formatters that respect each language

The editor level tooling is aimed at mathematical and technical authors, and it is implemented with language specific tools rather than approximations.

Document statistics use TeXcount for LaTeX documents and typst-wordometer for Typst documents, which the documentation describes as delivering accurate statistics that reflect the structure of each language rather than raw text length. For a paper full of equations, that difference is the difference between a word count a supervisor believes and one that does not need a caveat.

Formatting works the same way. LaTeX documents are formatted with tex-fmt and Typst documents with typstyle, applying consistent indentation and line separation without altering document semantics. Both tools operate entirely in the browser, work offline and stay synchronized across collaborators in real time, which means two people formatting the same file at once do not fight over it.

Mathematical expressions can be edited interactively using inline previews. Diagrams are handled by embedded editors, including Draw.io and a TikZ Editor, so a diagram can be created and edited collaboratively inside the project instead of being exported from a separate tool and pasted in.

Running it yourself: Node 24, pnpm and one script

TeXlyre is a self hostable web application rather than a hosted service, and the package metadata tells you what it needs. The package name is texlyre at version 0.13.3, the package manager is declared as pnpm 10.20.0, and the engines block sets the floors:

"engines": {
    "node": ">=24.13.1",
    "npm": ">=10.5.0"
},

Node 24.13.1 or newer is the floor, and npm 10.5.0 or newer is the floor for npm, with pnpm preferred through the packageManager field. The scripts section defines the development and production entry points, and the interesting part is that every task goes through a small wrapper at scripts/pm.cjs:

"scripts": {
    "start": "node scripts/pm.cjs run build:prod && node scripts/pm.cjs run test:check && node scripts/pm.cjs run preview",
    "predev": "node scripts/setup-assets.cjs",
    "dev": "node scripts/pm.cjs vite",

The dev script runs the wrapper against vite, with a predev hook that runs setup-assets.cjs first. The start script is the production path: it builds with the prod target, runs the test check, then serves the preview. A build target exists as well, chaining the plugin generation, the TypeScript compilation, the asset setup and the vite build.

The rest of the repository is a conventional modern front end: vite.config.ts, tsconfig.json alongside tsconfig.node.json and tsconfig.test.json, biome.json and eslint.config.js for linting, jest.config.cjs for tests, translations with a Crowdin badge for localisation, and a texlyre.config.ts at the root alongside the userdata configuration files that the build generates interfaces from.

AGPL-3.0-or-later, a young version line and active development

The licence is the first practical question for anyone thinking about running this. The README carries an AGPL v3 badge and the package metadata declares AGPL-3.0-or-later. For a self hosted web application that users reach over the network, the network use clause in the AGPL is the part that needs attention, and whether it fits your deployment model is a question for your own legal review rather than something this article can answer.

The other licence angle is the components. The project pulls in established open source pieces for the heavy lifting: SwiftLaTeX and BusyTeX for LaTeX, typst.ts for Typst, Yjs for CRDTs, FilePizza for file transfer, tex-fmt, typstyle, TeXcount and typst-wordometer for the tooling, plus Draw.io and the TikZ Editor as embedded diagram editors. Each of those carries its own licence, and the AGPL on the TeXlyre code does not relicense them.

On maintenance, the record is recent and busy. The repository is not archived and the last push was on 2026-10-16. Tagged releases moved quickly through the second half of 2026, with v0.11.0 on 2026-08-27, v0.12.0 on 2026-09-06 and v0.13.0 on 2026-09-30, while package.json already sits at 0.13.3. That gap between the tag and the manifest is the normal consequence of a project shipping patch versions from the main branch, but it means a deployment that pins a tag is running older code than a deployment that tracks main.

Editorial conclusion

Adopt TeXlyre when your group edits LaTeX or Typst together and wants compilation without a server, source that keeps working on a plane, and peer-to-peer sync. Skip it if you need the whole TeX Live package tree, if reverse SyncTeX on pdfTeX matters, or if AGPL-3.0-or-later is incompatible with how you intend to host it. Verify first that your toolchain matches the declared engines, node 24.13.1 or newer with npm 10.5.0 or newer under pnpm 10.20.0, and that the version you pin, currently 0.13.3 in package.json, matches the tag you want to deploy.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. Project website
3. README
4. Releases
5. TeXlyre/texlyre on GitHub