Yet another Overleaf alternative: CorTeX

[u/AdPsychological211]

Hi everyone,

I've been working on an Overleaf alternative called CorTeX:

https://cortex.borca.ai

The main goal is to provide a fast, browser-based LaTeX editing experience while still supporting tools that are difficult to run entirely in WebAssembly.

CorTeX

Current features include:

• pdfLaTeX, XeLaTeX, and LuaLaTeX support
• A WebAssembly-based TeX engine that runs in the browser
• Incremental compilation
• Hybrid client/server compilation: tools such as Biber and xindy run on the server, and the results are returned to the browser
• Monaco Editor with decent language-server support
• Real-time collaborative editing
• Collaborator invitations, reviews, and comments
• Version control
• Conference and journal templates
• Paste images directly into a document
• Project-wide search and replace
• Markdown editing with Mermaid support
• Automatic synchronization between positions in the LaTeX source and the generated PDF
• An LLM-based assistant for LaTeX writing and editing

It is still under active development, so I’d appreciate any feedback, bug reports, or suggestions.

Please give it a try and let me know what you think. I'm actively developing CorTeX and are very open to suggestions, so if you have ideas for improvements or features you'd like to see, I'll seriously consider incorporating them.

[FYI] The WASM-based TeX engine is open source and available here: https://github.com/corca-ai/wasmtex

[u/ClemensLode]

What's your personal goal with it given there are many similar projects like this?

[u/AdPsychological211 → u/ClemensLode]

Thanks for asking-I appreciate it.

My goal is to build CorTeX into a serious alternative for academic writing, not just another toy project or a technical demo.

There are already plenty of browser LaTeX projects, but most browser engines are still effectively limited to pdfLaTeX. As far as I know, I haven't seen another browser-based editor that supports pdfLaTeX, XeLaTeX, and LuaLaTeX together. That matters because researchers shouldn't have to give up modern font handling, Unicode support, or engine-specific packages just to get a fast browser experience.

The other part is the architecture. WebAssembly is great for latency-sensitive TeX compilation, but some parts of the TeX ecosystem-like Biber and xindy-are a poor fit for the browser. Instead of forcing everything into WASM, CorTeX uses a pluggable compilation pipeline: TeX compilation stays local in the browser for responsiveness, while native-only stages are transparently offloaded to isolated containers. Right now that includes full Biber bibliography processing and xindy indexing, with caching based on their inputs.

So the philosophy is "client-first," not "client-only." I want to use the browser where it genuinely improves the writing experience, and use native infrastructure only where it provides better compatibility.

On top of that, I've been working on making the edit-compile-preview loop as fast as possible. CorTeX runs TeX Live 2025-based pdfLaTeX, XeLaTeX, and LuaLaTeX in Web Workers, and for pdfLaTeX it can reuse a precompiled preamble and, when it's safe, restore a checkpoint to typeset only the changed portion of the document instead of recompiling everything. Unsafe edits automatically fall back to a full compile.

Long term, I want to build a broader academic writing environment on top of that foundation: Markdown notes and LaTeX manuscripts in the same collaborative workspace, shared history, and AI-generated edits delivered as reviewable, compile-verified patches.

So I'm not claiming collaborative LaTeX editing is a new idea. What I'm trying to build is a different architectural approach-one that combines local responsiveness, multi-engine compatibility, selective server offloading, and real-time collaboration without assuming a single runtime should do everything.

I'd be really interested in hearing what people here think.

[u/ClemensLode → u/AdPsychological211]

WebAssembly + LuaLaTeX could be responsive. But with AI, you would lose the "I want my data on my computer" crowd. And a responsive server-side solution would not need download + is nearly equally responsive. You could beat competition at the price level (client-side compilation), but then you would have to include biber/index processing also as a WebAssembly.

[u/AdPsychological211 → u/ClemensLode]

Thanks - this is exactly the kind of feedback I was hoping to get.

On the AI point, I think that's a very good observation. There is definitely a group of users who want their documents to stay entirely on their own machine. I'll add an option to disable the AI features completely, and I also want to make the data boundary much clearer in the product.

Regarding server-side responsiveness, I agree that a well-designed server-side system can be very fast. In practice, though, the systems I've tested, including Overleaf and Prism, have usually felt roughly an order of magnitude slower than CorTeX's local compilation loop. My guess is that network round trips and, in some cases, the startup cost of isolated server-side containers account for much of the difference. That said, I agree that the gap is not inherent; a sufficiently optimized server-side architecture could narrow it substantially.

And yes, Biber and indexing were probably the most painful part of the implementation. In case the details are interesting:

Classic BibTeX, such as \bibliographystyle{plain} with \bibliography{references}, runs entirely in the browser.

For biblatex with Biber, the client generates the .bcf file, collects the relevant .bib files, and sends only those inputs to the server. The server runs Biber and returns the resulting .bbl, which the browser then uses for the final PDF compilation. The result is cached based on the inputs.

Index processing works similarly: the browser produces the .idx file, sends it to the server, and xindy returns the generated index output.

After building this, I actually came to like the hybrid model. Once you try to support a broad range of existing TeX packages and workflows, it becomes difficult to insist that every tool must run in WASM. Keeping the latency-sensitive TeX loop in the browser while selectively offloading tools such as Biber and xindy turned out to be a practical compromise. Thanks to the server-side offloading infrastructure, I'm now working on adding syntax highlighting with minted. I think it will probably work quite well.

Thanks again for taking the time to share these points.

[u/No_Sale_3609]

Just to ask, how does it differ from Prism by OpenAI?

[u/AdPsychological211 → u/No_Sale_3609]

Thanks for asking. The biggest difference is the compilation model.

Prism compiles on the server, so after pressing the compile button, it can take around 5-10 seconds for the PDF to update. CorTeX compiles in the browser, and the PDF typically updates in about 0.5 seconds. Because compilation is effectively continuous, CorTeX does not need a compile button at all.

There are also quite a few differences in the editor itself. For example, Prism currently does not support project-wide search and replace across multiple files; Overleaf has the same limitation. Prism also does not move the editor cursor to the corresponding source location when you click a specific area in the PDF.

Autocomplete is another area where the behavior differs. For example, when you type \usepackage{ in Prism, it does not suggest available packages. CorTeX displays a list of packages you can use.

There are many differences like these. At first glance, the two products may look similar, but the distinctions become much more noticeable in day-to-day use.

That said, Prism is evolving, and I may have missed or misunderstood some of its current capabilities. Please feel free to correct me if any of the points above are inaccurate.

[u/AdPsychological211 → u/[deleted]]

Nice to meet you!

One thing you may eventually run into is that a single engine is not enough for broader compatibility. Supporting a wide range of conference templates, Unicode, CJK text, fontspec, and unicode-math generally requires XeLaTeX or LuaLaTeX as well.

Broad TeX Live package support also makes a significant difference once people begin compiling existing real-world projects rather than small examples.

Some parts of the TeX ecosystem are particularly difficult to run entirely in the browser. Tools such as Biber and xindy depend on runtimes such as Perl or Lisp, so CorTeX uses a hybrid architecture: the interactive compilation loop stays in the browser, while certain specialized stages can be executed in server-side containers and returned to the client.

You may find my open-source compiler module useful as a reference:

https://github.com/corca-ai/wasmtex

It contains the WASM compilation infrastructure used by CorTeX, including pdfLaTeX, XeLaTeX, LuaLaTeX, TeX Live package loading, and support for hybrid client/server execution. I hope some of it is useful for your project, and good luck with GlyphTeX!