AI-Generated SVGs Are Eating Infographics, One Token at a Time

Recently, my blog illustration method has changed again: from AI-generated images to AI-generated SVGs.

The reason is simple: Generating an image is too expensive, while SVG is code, it's text, and it's cheap.

As I used it, I discovered that cheapness is just its least remarkable benefit.

A Brief History of My Illustrations

In the early days, my blog illustrations came from only two sources: found online, or hand-drawn on a tablet. Neither was great. Images found online had inconsistent styles and always had those murky copyright issues; my own drawings... well, if you've seen an elementary school bulletin board, it was about that level.

Later, AI image generation capabilities took off. In November 2025, Google released Gemini 3, and with it came the image model codenamed Nano Banana Pro (official name Gemini 3 Pro Image). I saw a text-to-image prompt shared by an expert on X, tried it, and it worked well. I used it for a long time afterward and even wrote a dedicated piece, "Sharing a Commonly Used Text-to-Image Prompt". The core of the prompt was "hand-drawn style infographics": cartoon elements, keyword highlights, large white space. What I liked most about Nano Banana Pro was its ability to render clear, readable text within the image—Chinese was no problem.

But after prolonged use, problems started to emerge. AI image generation is "one-shot." Once you pull a satisfactory image from the gacha, it's fixed—want to change a single word or move an element? You have to regenerate, and re-rolling doesn't guarantee other parts stay the same. Moreover, the image is a black box: it takes up space, consumes bandwidth, can't be edited, and blurs when enlarged.

Finally, the money. With heavy use, I realized image generation is genuinely expensive.

Why Bitmaps Are Expensive

According to official pricing as of August 2026, generating a 1024×1024 image costs roughly $0.03–$0.13 for Google's Nano Banana series, and up to $0.21 for OpenAI's gpt-image-2 at the highest tier. A single image might seem okay, but illustration is never a one-image job—gacha pulling, prompt tweaking, re-rolling, it's common to go through a dozen or so images for one article, and several dollars are gone.

Why is it expensive? Because image generation and text generation are fundamentally different things. An image is drawn bit by bit from noise (hence the term diffusion model), and billing is calculated separately. Images are billed by "image tokens"—each image is fixedly converted to thousands of image tokens (a 1024×1024 image from Nano Banana Pro converts to 1,120 tokens), and the unit price of an image token is ten to three hundred times that of a text token.

Conversely, if you have a text model output the same content as SVG code, a few hundred to a thousand-plus text tokens will do it. Using a cheap model like Gemini 2.5 Flash-Lite to write it costs about $0.0004.

The same image: a few cents for a bitmap, zero-point-zero-zero-zero-something dollars for SVG. A one to two order of magnitude difference.

Condensed into a comparison chart:

SVG: The "Plain Text File" of the Graphics World

SVG is an old standard: the W3C formed a working group in 1998, and SVG 1.0 officially became a recommendation in September 2001—exactly 25 years old this year. It describes graphics using XML: a circle is <circle>, a rectangle is <rect>, text is <text>. Twenty-five years later, all modern browsers support it natively.

And for AI, the best part about SVG is: it's just a text file.

I discussed half of this logic back in May when I wrote "HTML: The Universal Expression Layer in the AI Era": AI is best at generating text, and text formats are naturally suited for precise modification. The cost difference calculated in the previous section is just the first consequence of "being text"—because it's text, it's cheap. SVG is the graphical version of the same story.

Get a feel for it. An infographic "originally" looks like this:

<svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 800 450">
  <rect width="100%" height="100%" fill="#f5f5f7"/>
  <rect x="40" y="40" width="720" height="370" rx="16" fill="#ffffff" stroke="#a8a8b0" stroke-width="2"/>
  <text x="80" y="118" font-size="30" font-weight="700" font-family="PingFang SC, Hiragino Sans GB, sans-serif" fill="#1d1d1f">On the Potential of SVG</text>
  <text x="80" y="156" font-size="16" font-family="PingFang SC, Hiragino Sans GB, sans-serif" fill="#6e6e73">An image is a piece of code</text>
  <circle cx="640" cy="260" r="90" fill="none" stroke="#3f6f24" stroke-width="3" stroke-dasharray="8 6"/>
  <text x="640" y="268" font-size="20" font-family="PingFang SC, Hiragino Sans GB, sans-serif" fill="#31571d" text-anchor="middle"><svg></text>
</svg>

Save this code as a file, throw it at a browser, and it renders as the image below—no intermediate steps:

This is what AI has been generating for me recently. Every single "image" looks like this: structured, with coordinates, with text. It is simultaneously an image and a piece of code that can be diffed, reviewed, and managed with git.

Cheapness Is Just the Beginning

Cheapness is just the entry ticket. What's truly interesting about SVG is that it turns an image from a black box into source code.

Cheap to modify. To change a detail in a bitmap, you can only re-roll—you say "move the title a bit to the left," and it might change the entire image. Changing a detail in SVG is changing one line of code. AI is far more precise at modifying code than generating images, and a human can also make the change. Honestly, I still have AI write the SVG for me 😂—but the point is, what it writes is a piece of code I can open anytime, change two lines, and save again.

Scales without blurring, and files are small. Vectors have no concept of resolution. 2x screens, 4x screens, projectors—no blurring. If you want a larger bitmap, you have to spend more money to generate a larger image; a piece of SVG is usually a few KB, while a 2K bitmap is easily several MB.

Images can be alive. You can write CSS and embed JS in SVG: hover highlights, click to expand, looping animations; inline SVG written with currentColor automatically switches with dark mode. Bitmaps can't do this—a PNG on a dark page is either glaring or washed out.

Making Images Move Is Also Just Code

The "alive" aspect mentioned above refers to SVG's own animation capabilities. Recently, while writing the "Introduction to Lua Programming" tutorial, I discovered another way to "move," and this discovery was more practical.

When writing the section on Dijkstra's shortest path, I wanted to create a demo animation for the algorithm: nodes being "fixed" one by one, edges turning green sequentially, the distance table updating cell by cell. This kind of graphic used to be very expensive—either frame-by-frame in After Effects, screen recording with post-production, or hand-coding a Canvas animation. But then I thought: since SVG is code, why can't animation also be code?

The essence of animation is a sequence of states. And an algorithm is inherently a change of states. Each iteration of Dijkstra is a clear snapshot: which points are fixed, which edges are being examined, what values are in the distance table. Write these states as data, and one template renders all frames:

# Each frame is a state description, the template renders it into SVG
{"title": "Round 2: Fix C, B changes from 4 to 3",
 "fixed": ["A", "C"],                    # Fixed points
 "hot_edges": [("B","C"), ("C","D")],    # Edges examined this round
 "dist": {"B": 3, "D": 10, "E": 12}}     # Distance table

Then screenshot frame by frame, composite into a GIF, and an algorithm demo animation is born. The GIF below was created this way—8 frames, without "drawing" a single frame throughout the entire process:

What's interesting here is the division of labor in this process: The state is provided by the algorithm, the visuals are provided by the template. Consistency between frames is natural—rendered by the same template, node positions, colors, and font sizes will never drift; to change the demo content, you change the state data, not the canvas. Describing states is most natural for a coder, and this is far more reliable than having AI "draw" an animation frame by frame—visual coherence is precisely what bitmap models are worst at.

Of course, not everything is worth animating. Content where state changes over time—algorithm iterations, state machine transitions, protocol handshakes, data flowing through pipelines—animated graphics can directly present the "time" dimension; whereas juxtaposed information like structural relationships and conceptual comparisons is actually clearer in static images.

One small detail: why save as GIF instead of using SVG animation directly? Because GIFs play everywhere inside <img> tags—blogs, Juejin, various platforms all support it; SMIL animation compatibility remains inconsistent to this day. SVG is the design source file, GIF is the distribution format—a continuation of the same logic as "draw in SVG, export to PNG for publishing."

I'm Not the Only One Doing This

At this point, you might think this is just personal preference. It's not. The documentation world has already paved this same road.

Using HTML for presentations has become a trend in the developer community since 2026. frontend-slides, which converts natural language or old PPTs into single-file HTML presentations, gained 27,000 stars in half a year; the single-file presentation tool Bento hit the front page of Hacker News (over a thousand upvotes), with a top comment stating bluntly: "Teams are moving from finished presentation software to hand-written HTML/JS solutions"; the HTML slides framework Slidev grew by about 10,000 stars in a year, reaching 48,000.

The motivation is exactly the same as on the graphics side. Hand-crafting a PPT is cumbersome—just like hand-writing SVG is tedious; having AI generate a PPT is also not worry-free—just like bitmap generation is fixed once created. 36Kr tested AI PPT tools and concluded that "what's generated is an 'image,' not an editable object; you can't even manually fix a single typo"; even WPS's own AI has turned to HTML layout rendering to improve the editing experience (reported by Pacific Tech News). PPT is a proprietary format, designed for software, not for AI. HTML is text, cheap for AI to generate, precise to modify, and can be put into version control.

The documentation world moved from PPT to HTML. What about graphics? The graphics world actually had the answer long ago: GitHub natively supports embedding SVG in Markdown, and since 2022 can directly render Mermaid code blocks; Prometheus's architecture diagram was drawn in draw.io, exported as SVG, and committed to the repository; the component diagrams on the Kubernetes official site are also SVG; charting libraries like D3 and ECharts default to SVG rendering. Using SVG for infographics is not a new invention; it has always been the default answer in the graphics world. It was only missing one thing: a cheap production method. Now AI has filled that gap.

The Boundaries of SVG

Of course, SVG is not a panacea. Photos, realistic illustrations, complex textures—these still need bitmap models, and you still have to spend the money when necessary.

What SVG excels at is structured graphics: infographics, architecture diagrams, flowcharts, cover images, charts. The good news is that the vast majority of illustrations needed for blogs and technical content fall exactly into this category. In other words, for blogging, SVG covers almost all my illustration needs.

Potential

Back to the question in the title: why do I say a 25-year-old standard has huge potential?

Because a format's potential never depends on itself; it depends on the cost of producing it. For over two decades, SVG was an awkward format that was "tedious for humans to hand-write and unmotivated for tools to support": who could bear hand-writing hundreds of lines of coordinates just to draw an architecture diagram? Now AI writes it, and a person only needs one sentence. For example, I asked AI to "draw a RAG architecture diagram, green connection points, light background," and a few seconds later, I got this image—which is simultaneously a piece of source code I can continue to modify:

Bitmap generation gets more expensive the more you use it, and it's fixed upon creation; SVG generation gets cheaper the more you use it, and it can still be modified after creation. When the cost of graphics and the cost of text no longer have an essential difference, the modification, version control, and remixing of graphics will all merge into the text workflow—git diff on an image will be a commonplace thing.

This is not a prediction; it's already happening on my blog.