Extension API: General HTML preview for LaTeX, Typst, AsciiDoc...

[HeavySnowJakarta]

Markdown previewing is builtin with Zed while we cannot preview even real-time HTML files. I have two questions here:

• How does Zed preview Markdown? Like VSCode to do with an HTML container?
• Is it possible to port the related API for other documents (as new extension APIs?)

[jansol]

• Zed has a completely custom renderer for Markdown which does not touch anything like a webview at any point (a webview is a huge extra dependency)
• Extensions are extremely limited in what they can do. Interfacing with the Markdown renderer from extensions is not possible at this time.

[HeavySnowJakarta]

so zed may need a custom rendering model which is decoupled from markdown. likely related gpui apis.

[malikdraz]

This is the exact category of API gap I am hitting.

Concrete use case: agents now commonly generate standalone local .html artifacts as part of an editor workflow. Examples include implementation-plan reports, design review boards, PR triage boards, local docs, and throwaway visual review files. The artifact is a normal project file, often self-contained, and the user wants to inspect it in Zed immediately next to the source that generated it.

The useful MVP does not need to be a full browser:

• Register .html as a previewable file type.
• Open the rendered preview as a normal Zed item/tab, including "open to the side."
• Render saved file contents or the current buffer contents.
• Refresh on save or manual refresh.
• Keep preview read-only.
• Provide a clear security policy for local file preview: no publishing, no upload/share, and sandbox or opt-in behavior for network/storage/script execution.

If this becomes an extension API, the missing primitive seems to be: an extension can register preview providers by file pattern, receive the file path/buffer content, and return either a safe native preview model or a constrained HTML preview surface. If arbitrary webview support is too large, even a first-party .html preview crate would validate the workflow and inform the later extension API.

This would cover real-time HTML preview, but the motivating workflow is even simpler: open a standalone generated .html file and review it inside Zed without leaving the editor.

[HeavySnowJakarta]

This is the exact category of API gap I am hitting.

Concrete use case: agents now commonly generate standalone local .html artifacts as part of an editor workflow. Examples include implementation-plan reports, design review boards, PR triage boards, local docs, and throwaway visual review files. The artifact is a normal project file, often self-contained, and the user wants to inspect it in Zed immediately next to the source that generated it.

The useful MVP does not need to be a full browser:

• Register .html as a previewable file type.
• Open the rendered preview as a normal Zed item/tab, including "open to the side."
• Render saved file contents or the current buffer contents.
• Refresh on save or manual refresh.
• Keep preview read-only.
• Provide a clear security policy for local file preview: no publishing, no upload/share, and sandbox or opt-in behavior for network/storage/script execution.

If this becomes an extension API, the missing primitive seems to be: an extension can register preview providers by file pattern, receive the file path/buffer content, and return either a safe native preview model or a constrained HTML preview surface. If arbitrary webview support is too large, even a first-party .html preview crate would validate the workflow and inform the later extension API.

This would cover real-time HTML preview, but the motivating workflow is even simpler: open a standalone generated .html file and review it inside Zed without leaving the editor.

I have to say rendering an HTML file is a complex thing no matter if it's generated automatically or written directly by an agent. If an HTML is rendered dynamically do you have to add a JavaScript engine to calculate the logic? or when there is an iframe you have to render the related webpage recursively? It can increase the size of the app so it may prefer to open the HTML file externally

[AMDphreak]

AsciiDoc / SoT tooling use case (browser workaround today)

Same API gap from the AsciiDoc side: we want a Zed extension with source-of-truth conversion (Asciidoctor / native engine), LSP diagnostics, and accurate highlighting via semantic tokens. In-editor HTML preview is the missing piece.

Today the workable path is:

1. Convert .adoc → HTML in a language server / sidecar.
2. Ask Zed to open the result with LSP window/showDocument (external: true) so the system browser shows it.

That works, but it is a poor substitute for open-to-the-side preview with scroll sync.

A useful MVP that would unblock AsciiDoc (and Typst/LaTeX/agent HTML artifacts) without a full embedded browser:

• Extension- or core-registered read-only HTML preview tab
• Refresh on save / buffer change
• Explicit local-file sandbox (no implied publish/upload; gated network)

Related:

• Webview via Extensions #21208
• Extension API: support custom read-only file previews #59598
• RFC: Visual Extension API - Allow Extensions to Render GUI #53403

[dereuromark]

I second this request.

Another use case for this: Carve, a lightweight markup language (post-Markdown). The language extension (markup-carve/zed-carve) covers highlighting, injections and outline via tree-sitter, but there is currently no way to offer a rendered preview next to the editor, which is the one feature markup users ask for first.

A read-only preview API as proposed here would be enough for this case:

• Extension declares it handles *.crv
• Gets the buffer content on change (debounced)
• Returns a structured preview model (blocks, headings, emphasis, code blocks with language for existing syntax highlighting, tables, images)

No webview needed for that. Markdown's built-in preview already proves the native renderer approach works; exposing a subset of that block model to extensions would cover Carve, AsciiDoc, Typst, reStructuredText and friends without pulling in a browser engine.

Happy to be an early adopter / test this against a real grammar once an experimental API exists.