🏷️ Discussion Type

Product Feedback

Body

Hello GitHub team,

I'd like to propose native rendering of static HTML files directly in the repository view, the same way Markdown is rendered today.

The friction. GitHub already gives .md files a great reading experience, but .html files are still shown as raw source. Anyone who keeps static reports, documentation, demos, or generated artifacts as HTML has to leave GitHub — spin up GitHub Pages, download the file, or route through third-party proxies like raw.githack.com — just to see what the file renders to. For a format the browser was built to display, that round trip feels backwards.

Why this matters more now. Markup formats have evolved with how we read: raw text → Markdown → HTML. In the AI-agent era this curve is accelerating, because HTML is readable by both humans and machines and lifts the ceiling Markdown puts on density and structure. This isn't a fringe view:

• Thariq Shihipar (engineering lead on Anthropic's Claude Code team) argues in "The Unreasonable Effectiveness of HTML" that agents should emit self-contained .html artifacts instead of walls of Markdown — trading "a document you'd skim for one you'd actually read."
• Andrej Karpathy has publicly pushed the same direction, recommending that you ask an LLM to "structure your response as HTML" and open it in the browser, and noting that most docs already "render to some pretty .html static pages."

As more tools and agents emit complete HTML outputs — reports, evaluation dashboards, styled docs, notebooks exported to HTML — HTML is becoming a primary artifact format, not an edge case. Rendering it natively would make these outputs reviewable where the code already lives.

You already do this for other formats. GitHub natively renders Jupyter notebooks, PDFs, CSV/TSV, GeoJSON/TopoJSON maps, STL 3D models, and sanitized SVG. SVG is a direct precedent: it's markup GitHub renders after stripping unsafe content. Static HTML is the conspicuous gap.

I understand the security history. I know why GitHub serves raw files as text/plain (+ nosniff) and isolates executable user content on a separate origin (*.github.io): the 2013 Pages domain migration and the raw-serving policy both exist to keep user-controlled HTML/JS off the github.com origin where session cookies live. This proposal is deliberately compatible with that history — it asks for static, sanitized rendering, never execution.

What I'm actually asking for. I'm not claiming "HTML without JavaScript is inherently safe" — script-free HTML/CSS still carries real vectors (CSS-based exfiltration, <form> phishing, <meta refresh> redirects, external-resource beacons, inline SVG). The ask is narrower and mirrors what GitHub already does for Markdown: render static .html through the same sanitize-and-isolate pipeline:

• an allowlist sanitizer (strip <script>, event handlers, <meta refresh>, dangerous tags) — the same machinery already applied to inline HTML in Markdown and to SVG;
• a bare sandbox iframe (no scripts, no form submission, no top-level navigation, no same-origin);
• CSP / Camo-style proxying for external resources;
• served from the existing user-content origin, never github.com.

Optionally, gate it behind an explicit "Preview HTML" button instead of auto-rendering. This makes a static HTML file exactly as safe as the inline HTML GitHub renders in Markdown today.

Related, existing demand. This builds on requests the community has already raised:

• #109580 — Support for HTML READMEs (README.html) asks for HTML to render as a README. My proposal generalizes it: preview for any static .html file at the file-view level, not just READMEs.
• #144037 — provide correct MIME types for raw downloads approaches the same pain from the raw-serving side.

A repository-level sandboxed preview addresses the underlying need more directly than either alone.

Thanks for considering this.