The common-knowledge answer

Answer 1a: Just ask the LLM for HTML.

It's the default move. Karpathy recommends it as a prompting tactic; Thariq uses it on the Claude Code team (both in Observation 1). The LLM produces HTML, the bytes render in a browser, you can read what's there.

What you don't get: any way for the file to say what it is. No manifest, no UUID, no integrity, no declared capabilities, no contract on what's inside. The file can't tell the next reader — human or LLM — what tool made it, what version it represents, or whether anyone has touched its bytes. Fine for "show me what you mean"; lossy for everything else.

The structured answer

Answer 1b: Ask for a Capsule.

The Core spec is one page — twelve numbered rules, designed to paste into an LLM prompt. What comes back is a sealed .html file with all of this baked in:

• Manifest — inline JSON declaring what the artifact is, who produced it, what it claims to be.
• Integrity hash over data + manifest — tampering is detectable.
• UUID + parents[] — stable identity, explicit lineage.
• Declared capabilities (Rule 7) — export, copy, download all guaranteed-implemented.
• Pre-rendered content (Rule 12) — the file still works with JavaScript disabled.
• No network dependencies (Rule 2) — every byte the file needs is inline.

The producer (LLM) becomes a first-class spec-aware participant — not "make some HTML" but "produce a Capsule per Core v0.3.0."

Core (one page) · full spec · worked examples.

View it

Answer 2a: Open it in a browser. Or upload to S3.

The default. The bytes open in any browser, no setup. Caveat: no shareable URL out of the box — you bring your own hosting.

Host it

Answer 2b: Host it on htmlbin.dev.

Format and host are different jobs.

Multiple hosting projects have independently converged on the same minimal shape — drop HTML, get a URL — and stayed out of the format-discipline business. htmlbin.dev launched May 2026, the same week as htmlcapsule. The two layers compose: a valid Capsule can be served by htmlbin or self-hosted, and the format stays hosting-agnostic. Architecture + positioning archive · format/host split documented in spec.

Filename versioning

Answer 3a: v1.html, v2.html, v3-final.html, v3-real-final.html.

The default. The version lives outside the file — in the filename, the email subject, the folder name. People work this way because they have to.

The cost: nothing inside the file knows about its own version. When the file is renamed, forwarded, copy-pasted, or unzipped from an archive, the version information rides with the filename. If the filename gets dropped — or "cleaned up" — the lineage breaks. The artifact can't speak for itself.

Identity + lineage, recorded inside the file

Answer 3b: uuid, capsule_version, parents[] — in the manifest.

Each Capsule carries three identity fields inside its own inline JSON manifest:

uuid — a stable identifier for this file (immutable; mint once, never change).
capsule_version — a version string the producer maintains (semver-friendly; bumped on each meaningful change).
parents[] — the UUIDs and titles of capsules this one was forked or derived from.

So the artifact knows what it is and what it descended from, regardless of filename. Paste a Capsule into a new editing session, and a capsule-aware producer records the parent UUID in its own parents[] array. The lineage chain stays intact across renames, forwards, and zip files — because identity lives in the bytes, not the filename.

This solves which version is this and where did it come from. It doesn't yet solve the HTML-diffs problem proper — for that, see Answer 3c on the review surfaces that can be built on top of this identity foundation. Full spec · Core (one page).

Git tracks files. Capsule tracks artifacts.

Capsule-aware diff · open work

Answer 3c: The HTML is the artifact. The manifest is the review surface.

Raw HTML diffs are noisy because the file is dense with runtime detail. But a Capsule has five required blocks, each addressable on its own — and a capsule-diff tool layered on the spec doesn't need to make humans read raw HTML at all. It compares each block separately and presents deltas at the right grain:

Output from such a tool might look like:

Capsule diff: a.html → b.html
· Manifest: capsule_version 1.0.0 → 1.1.0; +1 parent
· Data: 3 entries added, 1 modified
· Content: +120 chars of visible text
· Style: no change
· Runtime: no change
· Integrity: content_hash changed (expected; manifest re-stamped)

Not built yet. Parked in spec Appendix E until someone hits a real diff-review problem worth solving. When it materializes, the diff tool sits as a layer on the spec, not a spec change — the spec's existing structural discipline is exactly the foundation that makes a semantic diff tractable.