Markdown viewer: support `<a href>` and `<a id>` anchor links

[fbartho]

Pre-submit Checks

• I have searched Warp feature requests and there are no duplicates
• I have searched Warp docs and my feature is not there

Describe the solution you'd like?

Warp's Markdown Viewer should render raw HTML <a href="…"> links as clickable links, and <a id="…"> (or name="…") as named anchor targets that in-page #fragment links can jump to. Both are everyday patterns in hand-built READMEs and docs.

Expected behavior: <a href="https://…"> renders as a clickable external link. <a href="#target-section"> (and the markdown [text](#fragment) equivalent) scrolls to the element carrying a matching <a id="target-section"> (or heading slug, if Warp adds heading-based anchors as part of this work).

Is your feature request related to a problem? Please describe.

Hand-built tables of contents commonly pair <a id="section"> anchor targets with [Jump to Section](#section) links, or use raw <a href> tags directly for external links when an author wants attributes markdown can't express (e.g. title, target). Today neither raw HTML anchors nor anchor-target resolution work in Warp's viewer, so any doc using this pattern loses its navigation.

Concretely, today in Warp's Markdown Viewer (verified on this build):

Raw <a href="#target-section">/<a href="https://…"> tags render as literal text instead of clickable links, and the markdown-native [Jump to Target Section](#target-section) link resolves as a plain URL hyperlink rather than scrolling to the heading below it — there's no anchor-target resolution at all, HTML or markdown.

Additional context

Test case:

# Anchor links (`<a href>`, `<a id>`)

Should render: a clickable link to an external URL, a clickable in-page jump to the "Target Section" heading below, and a named anchor target. Currently: expect literal HTML text instead of live links, and the `[Jump to Target Section](#target-section)` markdown link to resolve as a plain URL hyperlink (not scrolled to the heading).

Jump via raw HTML: <a href="#target-section">Jump to Target Section</a>

Jump via markdown link (contrast): [Jump to Target Section](#target-section)

External link via raw HTML: <a href="https://warp.dev">Visit Warp</a>

<a id="target-section"></a>

## Target Section

This is the heading the links above should scroll to.

Code pointers. As far as I can tell:

• crates/markdown_parser/src/markdown_parser.rs's InlineToken enum has no HTML-tag token at all, so raw <a> tags never get special-cased on the .md render path.
• The paste-path parser (crates/markdown_parser/src/html_parser.rs) does style <a href> when converting pasted HTML to FormattedText, but that code path is only reachable from Notebooks clipboard paste — it's not wired into .md file rendering.
• There's no anchor/slug concept anywhere in the content model — FormattedTextHeader has no id/slug field, and I couldn't find any scroll-to-fragment infrastructure. This means both the <a id> half of this request and heading-based anchor resolution for markdown links ([text](#heading)) are new territory, not just a missing tag handler.

Related: this splits out one tag from #13652 (bulk raw-HTML-subset request, since closed in favor of per-feature issues). See also #13083 and #4720 — table-of-contents requests; working in-document anchor links are a prerequisite for any TOC feature. Sibling issues from the same split: #13721 (<img> sizing), #13726 (raw HTML tables), #10259 (<details>/<summary> — pre-existing request), #13732 (<br>), #13733 (<kbd>), #13734 (<sub>/<sup>), #13735 (align on <p>/<div>), #13736 (<picture>/<source>)

Operating system (OS)

macOS

How important is this feature to you?

3

Warp Internal (ignore) - linear-label:39cc6478-1249-4ee7-950b-c428edfeecd1

No response

---

Scope update (2026-07-18): cross-document fragment links (other-file.md#section) are in scope for the initial implementation PR (#13962) alongside same-document fragments — a fragment link should work regardless of whether its target is in the current document. This surfaced three latent defects in relative-link resolution the PR also addresses: bare file.md targets misclassified as domains (.md is a ccTLD in the public suffix list), #fragment suffixes never stripped before file lookup, and standalone viewer tabs lacking a document-relative resolution base. Explicit <a id>/<a name> anchor targets remain the follow-up phase.

[oz-for-oss]

@fbartho

Here's what I found while triaging this issue:

Thanks for splitting this out from #13652. This looks like a real Markdown Viewer feature gap: raw <a> tags are not currently treated as links/targets, and common slug/id-based in-page navigation is broader than the current heading-fragment behavior.

Maintainer details

I concluded that feature request for Markdown Viewer to support raw HTML anchor links and named anchor targets, including common in-page fragment navigation patterns..

Triage summary

This is a Markdown Viewer enhancement request for two related capabilities: rendering raw HTML <a href="..."> tags as clickable links, and supporting named in-document targets such as <a id="..."> / <a name="..."> plus common heading slugs.

Reproducibility: High. The supplied Markdown snippet is enough to exercise the requested behavior, and the current code supports only a narrower fragment-link path. app/src/notebooks/editor/view.rs sends #... link clicks to scroll_to_matching_header, and app/src/notebooks/editor/model.rs resolves those by URL-decoding the fragment and comparing it case-insensitively against heading text. That means a common slug such as #target-section will not match a heading whose rendered text is Target Section, and explicit HTML anchor targets are not represented.

Likely implementation area:

• crates/markdown_parser/src/markdown_parser.rs parses inline Markdown links and only special-cases a small HTML-style underline tag (<u>), so raw <a href>/<a id> input remains plain text on the Markdown file render path.
• crates/markdown_parser/src/lib.rs and crates/editor/src/content/markdown.rs would need a way to carry link targets and possibly named anchor metadata through FormattedText into the editor/notebook buffer.
• crates/markdown_parser/src/html_parser.rs already applies href styling while parsing pasted HTML, but that parser is separate from .md file rendering and does not solve named anchors.
• app/src/notebooks/editor/model.rs, app/src/notebooks/editor/view.rs, and crates/editor/src/content/outline.rs are the current in-page fragment navigation path and would likely need slug/id target resolution beyond exact heading text matching.

Duplicate check: I enumerated all open non-PR issues and also checked recently closed issues. #13721 and #13726 are sibling raw-HTML Markdown Viewer requests, #13083 and #4720 are broader table-of-contents/navigation requests, and #13652 is the recently closed parent raw-HTML-subset request that this issue intentionally splits out. I did not find two existing issues that duplicate this specific <a href> / <a id> anchor-link request, so this should not be labeled as a duplicate.

No reporter follow-up is needed for initial triage; the remaining decision is product/implementation scope, especially whether to support only <a> tags, CommonMark-compatible raw HTML more broadly, GitHub-style slug generation, explicit id/name targets, or some combination.

This is my automated analysis and may be incorrect. A maintainer will verify the details.

Powered by Oz