Summary:
Markdown became the default AI output format for reasons that made sense when context windows were tiny and every token counted. Those constraints are gone. The outputs got longer, the format stayed the same, and now the bottleneck in AI-assisted work is not generation speed. It is human review. If your team is handing you walls of AI-generated text, nobody is actually reviewing anything. Asking for HTML output instead is the single fastest change that makes AI work something people can actually engage with, approve and act on.
Who this article is for:
Marketing leaders, agency teams, web developers and business owners who are already using AI tools every day and are frustrated that the output is technically correct but nobody actually reads it.
Key takeaways:
- Markdown became the default AI output format for reasons that no longer apply. Context windows were tiny and every token counted
- Asking AI for HTML output instead of markdown turns a document people skim into an artifact people engage with, because HTML carries color, layout, tables, diagrams and spatial structure that markdown flattens into bullet points
- The bottleneck in AI work is no longer generation speed. It is human review. You cannot approve what you will not read
- HTML costs roughly two to three times the tokens of equivalent markdown, and that trade-off is worth it when a human has to understand, approve or act on the output
- Markdown still wins for version-controlled documents, hand-editing and agent-to-agent communication where no human is reading
- One self-contained HTML file carries its own styling and structure, opens in any browser and can be shared as a single attachment or link
What’s inside:
- Why markdown won as the default AI output format and the exact point where it broke
- Notes from Matt Vanderpol’s WordCamp US 2026 session on teaching AI tools your process during a live WordPress build
- What changed in our own agency work after we switched to HTML output, including client-facing website mockups
- Nine categories of work where HTML output beats markdown with a side-by-side comparison
- The honest case against HTML output, including token cost and version control
- Prompt patterns you can use today to start getting HTML output from the tools you already have
- What this shift means if you are paying an agency or an internal team to use AI on your behalf
The WordCamp session that changed how we ask for output
WordCamp US 2026 ran August 16 through 19 at the Phoenix Convention Center. Over 1,100 people registered, thousands more watched the livestream and more than 50 speaker-led sessions ran across four tracks. It was 111 degrees outside. Golf carts shuttled people between the hotel and the convention center.
Most of the AI track was what you would expect in 2026. Agents, workflows, prompt strategy and a lot of well-earned caution about trust. Then Matt Vanderpol got up on the AI track and gave a session called Teaching AI Tools Your Process: Notes From a WordPress Site Build, and the most useful thing in it was not a tool, a plugin or a model.
It was a change to the format he asks for.
Vanderpol is a full-stack developer with close to 30 years in the industry, focused on WordPress theme and plugin development. Earlier this year he was the sole developer on a new WordPress build, and his talk was about the practice of correcting AI mistakes, capturing what he learned and feeding it back so the tools improved instead of just moving faster. Buried in his list of process improvements was a line that deserved its own session: ask for HyperText Markup Language output instead of HTML markdown when richer visualizations are helpful.
We have been running that change at Big Red Jelly for a few months now. It has done more for how our leadership, our team and our clients understand AI-assisted work than any model upgrade in the same window.
Why markdown became the default, and why that default broke
Markdown won for good reasons. It is cheap in tokens, it is readable by both humans and machines, it commits cleanly to Git and anyone can edit it in any text editor. When AI tools first became useful for real work, those advantages were decisive.
The token argument in particular used to be overwhelming. Simon Willison, who has been writing about this space longer than most, pointed out that he had defaulted to asking for markdown since the GPT-4 era, when an 8,192-token limit made markdown’s efficiency worth protecting. When your entire budget for a response is a few thousand tokens, spending them on HTML tags instead of pound signs is indefensible.
That constraint is gone. Context windows now run into the millions of tokens. And while the format stayed the same, the outputs got dramatically longer. Markdown also starts to fail when teams need to review complete web pages rather than plain-text artifacts.
Here is where it broke. A 50-line plan is something you read. A 1,000-line implementation document is something you skim, ignore or hand back to the model to rewrite. Thariq Shihipar, an engineering lead on Anthropic’s Claude Code team, made this point bluntly in a widely circulated May 2026 essay: he does not read markdown files past about 100 lines and he cannot get anyone else in his organization to read them either.
Read that again, because it is the whole problem. The person who knows the most about the work is not reading the work. And if the reviewer is not reading, the review is theater. Bad assumptions ship. Wrong architecture ships. A design direction nobody actually looked at ships.
Markdown’s visual toolkit is headers, bold text and bullet points. That is the entire kit. When an AI tool wants to communicate severity, it reaches for emoji. When it wants to communicate a diagram, it draws ASCII. When it wants to communicate a spatial relationship between four modules, it writes a nested list and hopes you can hold it in your head.
What actually changed in May 2026
Two things happened within days of each other. Andrej Karpathy posted a recommendation to ask your model to structure its response as HTML and view it in a browser, framing it as a natural progression: raw text, then markdown, then HTML and eventually something interactive. Around the same time, Shihipar published his essay arguing that markdown had become a restricting format as agents got more capable.
What made the argument land was not the reasoning. It was the proof. Shihipar shipped a companion gallery of 20 self-contained HTML files, each one generated by an agent, each one replacing something you would have skimmed. Side-by-side comparisons of three approaches to the same problem. A complete webpage rendered as an annotated diff with severity tags and jump links. Design tokens rendered as swatches you can copy from. An animation sandbox with sliders. A drag-and-drop ticket triage board with an export button.
The thesis spread fast and drew real disagreement, which InfoQ covered in June. The objections are covered below, because several are legitimate. But the core observation holds: goal communication, specification refinement and output review are now the bottleneck in AI-assisted work, and the format of the output determines whether a human clears that bottleneck or waves it through.
Notes from a real WordPress build
What made Vanderpol’s session worth writing about is that he was not theorizing. He was reporting from a shipped site.
Two of his examples stuck with the room. The first was a mega-menu navigation with a dead click zone, the kind of bug every WordPress developer has chased. The AI’s first move was to write a complicated JavaScript event handler, a reminder that it can generate code quickly but still needs team rules so simple fixes do not get overcomplicated. The actual fix was a few CSS utility classes on the link. That is a small story with a large lesson: the tool reached for complexity because nothing in its context told it that this team prefers the simplest possible solution. That is a process gap, not a model failure.
The second was a tangled Tailwind class string that felt wrong before he could articulate why. He ran four AI agents in parallel to get different viewpoints, used the comparison to diagnose the problem, cleaned it up and codified a rule that has held since.
Both examples point at the same practice, especially in web development workflows. You are not just prompting. You are teaching, and the lessons need somewhere to live. Vanderpol’s third process improvement was keeping those lessons portable so the learning survives a migration to a new model, which is the right instinct. The rules you teach a tool are an asset. The tool is not.
His first process improvement, the HTML output change, is the one that generalizes furthest beyond development work. It is not a developer trick. It is a communication decision.
What working HTML code output changed in our work
The theory is easy to nod along with. The practice is where it earns its keep.
Before the switch, a lot of what was delivered upward and outward was words. Long, correct, well-organized words. A summary for leadership was a wall of prose someone had to absorb. A recommendation to a client was a document they had to read carefully to understand what was actually being proposed. The information was all there. The comprehension was not.
Since moving to HTML output as a default for anything a human has to act on, three things changed, and all three were measurable in behavior rather than in a metric dashboard.
Leadership responds differently. A status update with a colored timeline, a small chart and what shipped versus what slipped gets a reply. The same information as a bulleted markdown summary gets a thumbs up, which is what people send when they have not read something.
Clients understand faster. There is significantly less reading and a great deal more understanding. When a client can see the thing instead of parsing a description of the thing, the questions they ask get better and the approval cycle gets shorter. Fewer rounds of “I think we may have been talking about different things.”
Mockups became almost free. This is the one that surprises most people. With HTML output, AI can generate five or six complete page variations in HTML for client review, each one themed entirely differently, for a fraction of the effort that used to take. Instead of describing three creative directions and asking a client to imagine them, you hand over pages they can look at and react to. Reaction is worth more than imagination every single time.
The underlying reason all of this works is boring and important: everything lives in one file. Data, styling, structure, layout, and images, all self-contained. No build step, no dependency, no export. It opens in any browser on any device. You attach it to an email or drop it in a Slack thread and the person on the other end sees exactly what you saw.
Yes, it costs more tokens. The honest case against is below. In our experience the trade-off is not close.
Where HTML output beats markdown
Not every output should be HTML. The useful question is what kind of work you are asking for. The wins group into nine categories, and they map cleanly onto agency and marketing work:
Exploration and planning. Three approaches to the same problem, side by side. You point at one instead of reading three sequential walls of text and trying to hold them in your head.
Code review and understanding. An annotated diff, or a module drawn as boxes and arrows. Diffs and call graphs are spatial. Markdown flattens spatial information into lists.
Design. Design tokens as swatches, or every state of one component on a single sheet. HTML is the medium the design system ships in, so it is the natural format to discuss it in. An ai html code generator can also produce semantic html for component states that are easier to review.
Prototyping. A clickable flow, or a transition with sliders for duration and easing. Motion and interaction cannot be described, only felt. Five seconds of clicking beats a paragraph of prose.
Illustrations and diagrams. Inline SVG figures, or a real flowchart of a process. The model gets an actual pen instead of ASCII art, and you get vector output you can reuse.
Decks. A short presentation as one file you arrow-key through. No Keynote, no export step, no version that only opens on one machine.
Research and learning. An explainer with collapsible sections, tabs and a glossary. Scaffolding makes an unfamiliar topic navigable instead of linear.
Reports. Weekly status, campaign recaps, incident timelines. A little color and structure turns something people skim into something people read.
Custom editors. A throwaway builder for the exact thing you are working on, with an export button. Sometimes it is hard to describe what you want in a text box. Drag it instead, then export it back.
That last category is the one most teams overlook. You can ask for a disposable tool built for one task, use it for an hour, export the result and throw it away. Prioritizing 30 items is faster by dragging than by describing. The export button is what keeps it honest, because whatever you did in the interface comes back out as something you can paste, commit or send.
The benefits of switching to HTML output
If you are weighing whether this is worth changing your team’s habits over, here is the case in plain English:
- Higher information density per screen. Color, layout, tables and position all carry meaning. Markdown has to spend words on things HTML can show
- Real review instead of rubber-stamping. The whole point of a review step is catching what is wrong before it gets built. That only happens if the reviewer engages with the artifact
- Fewer clarification rounds. When a designer, a developer and an account lead are all looking at the same rendered artifact, the extra token cost is paid back immediately in meetings you did not have to schedule
- Shareability with no friction. One file, zero dependencies, opens anywhere across browsers. No “can you export that to PDF,” no broken formatting, no plugin required
- Client-facing without translation. Internal AI output usually needs a human to rewrite it before a client sees it. Well-structured HTML output often does not, which lowers the barrier for people with no coding experience
- Faster creative exploration. Multiple themed directions produced in the time it used to take to describe one
- Better questions from stakeholders. People who understand what they are looking at ask sharper questions, and sharper questions produce better work
When markdown still wins
The strongest version of this argument admits where it does not apply. The pushback on Shihipar’s essay was substantial and some of it is right.
Token cost is real. Clean HTML runs roughly two to three times the tokens of equivalent markdown and generation takes noticeably longer. For a one-off artifact a human is going to read, that is a rounding error. For a high-volume API pipeline running thousands of times a day, it compounds into a line item.
Version control gets ugly. Markdown diffs are clean and readable. HTML diffs are noisy. If your document lives in Git and you review what changed between versions, markdown is still the better format for that specific job.
Hand-editing. This is the objection with the most teeth. You can edit markdown anywhere with anything. Editing HTML by hand requires either front-end skill or a round trip back through the AI tool, and markdown is still easier when you want to create HTML from scratch by hand. If you are going to revise a document ten times yourself, markdown will be faster.
Agent-to-agent communication. If no human is ever going to look at it, visual hierarchy is wasted effort. Reasoning traces, intermediate steps and data handed between tools should stay in the cheapest format that works.
Generated JavaScript deserves scrutiny. Reading a document and running a document are different activities. If a generated artifact includes scripting and you are opening it with real data in the browser, AI can help fix errors, but generated files still need review before use, so apply the same judgment you would to any code you did not write.
The working rule is simple: HTML when the output is meant to be understood by a person and you need working code a person can inspect, not just text output. Markdown when you are going to edit it yourself repeatedly, commit it or hand it to another machine.
How to start today
You do not need a new tool, a new project, or a separate platform to try this. You need to change how you ask. These prompt patterns work in any AI tool that can produce files or artifacts.
1. Add the format to the request, not as an afterthought. “Create this as a self-contained HTML file I can open in a browser” at the end of a prompt does most of the work, though the quality of the input still shapes the result.
2. Name the job, not just the topic. “Build pages in HTML that compare three approaches to this, with trade-offs called out inline” produces something very different from “explain three approaches.”
3. Describe the layout in plain language. Many tools do better when you state the sections, hierarchy, and visual structure clearly before asking for code.
4. Ask for the thing to be self-contained. Specify no external dependencies and no CDN links. You want one file that works offline and still works in six months.
5. Some teams use templates for recurring reports or mockups. That works well as long as the output stays self-contained.
6. Request an export path. If you are asking for anything interactive, ask for a button that copies the result back out as text or JSON. Without it, whatever you do in the interface is trapped there.
7. Save the rule. Put your format preference into your tool’s persistent instructions so you stop restating it. This is the portability lesson from Vanderpol’s session: the standards you teach should outlive the session and the model.
8. Start with one recurring document. Pick the weekly status update or the campaign recap that nobody reads and rebuild it as HTML for four weeks. Watch whether replies change, and let teams launch the test immediately without waiting for a broader rollout.
What this means if you are paying someone to use AI-powered tools
Every agency and internal team is using AI now. The differentiator was never access to the tools. It is whether anyone is actually reviewing what the tools produce before it reaches you. A team that hands you a wall of AI-generated text is asking you to trust a process you cannot inspect. A team that hands you a rendered artifact you can look at, react to and approve, with answers to the obvious review questions and not just visuals, is showing their work.
So when you are evaluating a partner, ask a version of this question: how do you review AI-assisted work before it reaches me, and what does that review look like? The answer tells you more about the quality of the work than any credential.
This is the same principle that has always driven good agency work. Show, do not describe. AI did not create that standard. It just made it much easier to meet and much more obvious when someone is not meeting it.
At Big Red Jelly, we bring the same standard to AI-assisted work that we bring to everything else: if you cannot see it, we have not finished explaining it. Schedule a free discovery call and we will walk you through how we plan, build and report on your project, or start with a free brand and website audit to see where you stand.
Want more from our team’s WordCamp US 2026 takeaways? Read Connor Biggar on the skills that separate AI users from AI leaders [UPDATE: replace with live BRJ blog URL for Connor’s WordCamp post] and what WordCamp taught us about building for the agentic web. If you are thinking about how AI changes your organic visibility, start with The New Rules: AI Overview Optimization and our breakdown of AI adoption statistics. For the fundamentals behind everything we build, see our guide to the fundamentals of web design and our blogging and website content services.
Key takeaways
- Markdown became the default AI output format under constraints that no longer exist. Context windows grew, outputs got longer and the format stayed the same
- The bottleneck in AI-assisted work has moved from generation to human review. A correct document nobody reads is a failed document
- Asking AI for HTML instead of markdown gives the model color, layout, tables, spatial structure and diagrams, which is the difference between describing something and showing it
- The strongest use cases are comparisons, reviews, design directions, prototypes, reports and throwaway editors. Anything with shape
- HTML output shortened approval cycles, improved leadership engagement and made multi-direction website mockups fast enough to be routine
- HTML costs two to three times the tokens and produces messy diffs. That trade-off is worth it whenever a human is the audience and not worth it when one is not
- The lessons you teach your tools are the durable asset. Save your format standards somewhere portable so they survive your next model change
Frequently asked questions about using an AI HTML code generator for HTML output
What does it mean to ask AI for HTML instead of markdown?
It means requesting that the tool deliver its answer as a self-contained HTML file you open in a browser, rather than as a markdown document you read as text, so it can create html directly from a prompt. The content is the same. The difference is that HTML can use color, tables, layout, spacing, position and inline SVG diagrams to carry meaning, while markdown is limited to headers, bold text and bullet points. In practice this turns a document you would skim into an artifact you would actually study.
Does HTML output make the AI smarter or more accurate?
No. The model’s reasoning does not improve because you changed the output format. What improves is your ability to catch what is wrong. Most of the value comes from the human staying engaged long enough to notice a bad assumption before it gets built. HTML does not make AI smarter. It makes AI output consumable.
How much more does HTML output cost in tokens?
Clean HTML code typically runs about two to three times the tokens of equivalent markdown and generation takes longer. For a single artifact that a person is going to read and act on, that cost is small relative to the time saved in clarification rounds and rework. For high-volume automated pipelines where no human reads the output, the cost compounds and markdown remains the better choice.
When should I still ask for markdown?
Use markdown when you will hand-edit the document repeatedly, when it lives in version control and you need clean diffs, when it is a durable record like a running specification or a knowledge base, or when it is being passed between automated tools with no human reader, especially when another generator or pipeline is the primary consumer. The rule of thumb is simple: HTML for reading and reviewing, markdown for editing and storing.
Do I need to know how to code to use HTML output?
Not to consume it. An HTML file opens in any browser by double-clicking it and you never need to look at the markup. Where coding knowledge helps is editing. If you want to change something in the file, you either need front-end skills or you go back to the AI tool and ask for the revision. That is the main practical trade-off compared with markdown, which anyone can edit in any text editor.
Can I use HTML output for client-facing deliverables?
Yes, and this is where the biggest return tends to appear. Mockups, campaign recaps, status reports, design direction comparisons, proposals, and FAQ-style deliverables all land better as rendered artifacts than as text. Everything is contained in one file, so you attach it to an email or drop it in a shared folder and the client sees exactly what you see, on any device, with no software required.
Is it safe to open AI-generated HTML files?
Static HTML with styling and content is no riskier than any other document, unlike more complex interactive outputs. Apply more care when the file includes JavaScript, especially if you plan to paste real data into it or use forms that collect input. Treat generated code the way you would treat any code you did not write yourself: look at what it does before you run it and do not feed sensitive data into an interactive artifact you have not reviewed.
Where did this idea come from?
It surfaced publicly in May 2026, when Andrej Karpathy recommended asking language models to structure responses as HTML and Thariq Shihipar, an engineering lead on Anthropic’s Claude Code team, published an essay arguing that markdown had become a restricting format as AI agents grew more capable. Matt Vanderpol brought the practice into WordPress work in his WordCamp US 2026 session on teaching AI tools your process during a live site build, and it is useful whether you are using an AI-powered builder or a coding assistant.
How do I get my team to actually adopt this?
Do not roll it out everywhere at once. Pick one recurring document that you know people are not reading, and whether your team prefers a simple drag and drop interface or a static file for review, rebuild it as HTML for a month and watch whether the replies change. Then save the format preference into your tools’ persistent instructions so nobody has to remember to ask, even if some tools let users write CSS or adjust styling rules there; the key is saving the standard. Standards that live in a tool get followed. Standards that live in a wiki do not.
