Ask Your Claude Agent for HTML — A One-Line Trick That Makes AI Output 10× Easier to Read

Module objectives:

• Understand what actually happens when an agent "replies in text."
• See the concrete moment (from the source video) where plain text breaks down.

When you ask an AI agent a question — "give me a few ways to structure this feature," "review this code," "compare these options" — the default answer comes back as a block of prose, often with lettered or numbered lists: option A, option B, option C, option D.

That format is fine for a sentence or two. It falls apart the moment the answer has any real structure to it. You end up doing the work the format should have done for you: re-reading the block, mentally building a table to compare the options, scrolling up and down to remember what "C" said versus "B."

In his post on the technique, Thariq Shihipar — the Anthropic Claude Code engineer who popularized it — puts the ceiling bluntly: plain markdown "doesn't scale past ~100 lines." Past that, people stop actually reading and start skimming, and the detail you waited for gets lost.

The source video gives a clean, real example. The creator was building an app ("Budget SF") and asked their agent for help. The agent replied the usual way — "ABCD options," in their words, that were "not easy to understand."

So they changed one thing. They asked: "Give me an HTML."

The agent came back with a structured page showing the same options laid out with design examples — and, as the creator says, they were "able to now think of what option to choose easily."

Nothing about the agent's underlying answer changed. The information was identical. Only the format changed — from a paragraph you decode to a page you scan. That is the entire trick.

---

Module objectives:

• Get the exact prompt wording that works.
• See a before/after of the same answer in two formats.
• Understand why structure helps both you and the model.

You do not need a clever, engineered prompt. The engineers who popularized this recommend asking directly and plainly. Any of these work:

Give me that as an HTML file.

Make an HTML artifact instead of plain text.

Create a single-file HTML page I can open in a browser. Use a table to
compare the options, color-code the recommended one, and keep it to one file
with inline CSS so I can open it directly.

The third version is the one to keep in your back pocket. The extra detail —

"single file," "inline CSS," "open it directly" — tells the agent to produce

something you can double-click and view immediately, with no build step and no

extra files to manage.

You can also make it the default for a whole working session:

For the rest of this session, whenever you show me options, comparisons, or a
review, output a single self-contained HTML file instead of plain text.

How to actually view it. If you're in a chat-style tool (Claude.ai, the

Claude desktop app), HTML often renders right in the artifact/preview pane — no

extra step. If you're in a coding agent (Claude Code, Cursor), ask it to **save

the page to a file** like output.html, then double-click that file to open it

in your browser. Either way, the goal is the same: a page you look at, not text

you decode.

Before — the default text reply (what slows you down):

There are four ways to structure the budget screen. Option A uses a single
scrolling list, which is simple but hard to compare. Option B groups by
category with collapsible sections, better for many categories but more taps.
Option C is a two-column layout with totals on the right, good on desktop but
cramped on mobile. Option D is a dashboard with charts, most visual but the
most work to build...

To compare those, you have to hold all four in your head at once.

After — ask for HTML, and the agent renders this instead:

Create a single HTML file with a comparison table: columns = Option, Best for,
Effort, Mobile-friendly. Color the row you'd recommend green. Inline CSS only.

Now the same four options arrive as a table you can take in at a glance — one

row each, the recommended one highlighted, effort and mobile-friendliness in

their own columns. You make the decision in seconds instead of minutes. The

content didn't get better; it got legible.

The video makes a second claim worth taking seriously but not overstating: that

"with HTML, agents can think better — they can structure their thoughts better."

There is a real, documented idea underneath that — but be precise about it.

Anthropic's official prompting guidance is about **structuring the input you give

Claude*, not the output: its docs state that "XML tags help Claude parse complex

prompts unambiguously… wrapping each type of content in its own tag reduces

misinterpretation."* In other words, structure is something Claude is demonstrably

good at reading and producing.

Asking for HTML output is the output-side version of that same instinct: you're

nudging the model to commit to an organized shape (headings, rows, sections) rather

than free-flowing prose. Whether that makes the model "think better" is a softer,

unproven claim — but it reliably makes the model commit to a structure, and a

committed structure is easier for you to evaluate. Take the readability benefit as

real; take "the AI thinks better" as a plausible bonus, not a fact.

---

Module objectives:

• Match the trick to the jobs it's genuinely built for.
• Avoid using it where it adds nothing.

This trick is not "always use HTML." It pays off when the answer has structure

that a browser can render better than prose can. The high-value cases — the ones

Thariq Shihipar highlights in his post, and that match where the trick actually

earns its keep:

1. Comparisons & options — multiple approaches in one grid you can scan side by side (exactly the video's "Budget SF" case).
2. Code review — color-coded severity, inline annotations, and rendered diffs instead of a flat list of comments.
3. Reports & research briefs — synthesized findings with small SVG diagrams and annotated snippets, not 300 lines of markdown nobody finishes.
4. Design prototypes — an interactive page (sliders, toggles) you can actually click, rather than a description of an interface.
5. Decision tables & dashboards — anything where a table, color, or a chart carries the meaning faster than a sentence.

The common thread: **the output is something you review, compare, share, or act

on** — not a single fact or a short reply. If the answer is "yes, use useMemo

here," asking for HTML is silly. If the answer is "here are five tradeoffs across

three dimensions," HTML earns its keep.

A nice side effect: an HTML file opens in any browser with no special tooling, so

it's trivial to share with a teammate who isn't in your editor.

---

Module objectives:

• Know the concrete costs so you use the trick deliberately.
• Know when plain text or markdown is the better choice.

The same engineer who recommends HTML is upfront about its downsides — and so

should you be:

• It costs more tokens. HTML is roughly 2–4× more verbose than markdown for the same content. More tokens means slightly slower responses and higher API cost. For a quick answer, that overhead buys you nothing.
• Git diffs get noisy. If you commit AI-generated HTML, the diffs are "noisy and hard to review compared to markdown." HTML is a great viewing format and a poor version-controlled-source format. Don't check generated HTML into a repo where humans review diffs.
• It's not for editing. Markdown's whole advantage is that a human can edit it by hand. HTML output is meant to be read, not hand-edited. If you need a document you'll keep tweaking in plain text, stay in markdown.

Reach for plain text / markdown — not HTML — when:

• The answer is short (a fact, a yes/no, a one-line fix). HTML overhead with no payoff.
• The output is source you'll version-control and review in diffs (READMEs, docs, commit messages).
• You need to edit the result by hand afterward.
• You're piping the output into another tool that expects plain text or markdown.

And the honest framing of the headline one more time: **"10× easier to read" is a

figure of speech.** No source measured it. What's actually true and defensible is

narrower and still useful — for structured, multi-part answers, an HTML page is

meaningfully faster to scan and compare than a block of prose. Use the trick

because that's real, not because of a number.

---

Resources & Sources

• Named source (this guide's basis): "Anthropic Engineers recommends HTML for everything!!" — YouTube — the short demo showing the "Give me an HTML" trick on the "Budget SF" app.
• Origin of the technique: Thariq Shihipar (Anthropic Claude Code engineer), May 2026 post "The Unreasonable Effectiveness of HTML." Summaries and the markdown-vs-HTML debate: Thurrott, explainx.ai.
• Anthropic prompting docs (structure helps Claude parse): Use XML tags to structure your prompts — Claude Docs.

One-line takeaway: When an agent's answer has real structure — options, a

review, a comparison — add five words to your prompt: "Give me that as HTML."

You'll scan in seconds what used to take minutes. Skip it for short answers and

anything you'll edit or commit.