In 1998, Adobe and Microsoft were at war over who would own vector graphics on the web. Adobe teamed with Sun to push Precision Graphics Markup Language, rooted in PostScript, the format Adobe had used to dominate desktop publishing. Microsoft and Macromedia countered with Vector Markup Language, already shipping inside Internet Explorer as a fait accompli. Six competing proposals in total landed at the World Wide Web Consortium that year. Microsoft's position was blunt: Vector Markup Language was an implemented, shipped product, and the W3C was not authorized to change it.

The W3C ignored all six proposals and built something new. Scalable Vector Graphics, formalized in 2001, took what was useful from each submission and belonged to none of them. It was Extensible Markup Language-based, open, and stored images as readable text rather than pixels. Every shape is a coordinate. Every label is a character. Nothing is burned into a color grid.

Then Flash won anyway. Adobe eventually bought Macromedia, acquired the Flash format it had been fighting, and quietly shelved its own SVG browser plugin. Microsoft kept Vector Markup Language alive inside Internet Explorer for years. SVG survived but sat mostly dormant for a decade, too principled to die and too orphaned to thrive.

What revived it was not a new standard or a browser mandate. It was the architecture of large language models. A model that can write code can write SVG. And writing SVG costs almost nothing compared to generating a raster image through a diffusion pipeline.

The compute gap is not a footnote

Research examining ten common AI tasks across 88 models on the Hugging Face platform found that the least carbon-intensive text generation model produces roughly 6,800 times less carbon than image generation models (Luccioni et al., Hugging Face / Carnegie Mellon University, 2023). A separate analysis put the energy cost of a single high-quality GPT-4o image at approximately 5.6 grams of carbon dioxide equivalent, against roughly 0.03 grams for a comparable text prompt (Scope3, 2025). The ratio is not a rounding error.

The mechanism behind that gap is the diffusion process itself. Generating a raster image requires many iterative forward passes through a large neural network, refining noise into structure across dozens of steps. Generating SVG requires the model to write structured text code, the same operation it performs for any other output. When Claude or any capable language model produces an SVG, it is not invoking a separate image model. It is writing markup.

That distinction matters at scale. One viral image generation trend, the Ghibli-style rendering wave of 2024 and 2025, consumed an estimated 4,309 megawatt-hours of energy and produced approximately 2,068 metric tons of carbon dioxide emissions (G-TRACE / arXiv, 2024). Enterprises running content operations at volume face that math every quarter.

LLMs did not discover SVG. They rediscovered it.

The practical reason language models gravitate toward SVG for visual output is structural: SVG is code, and these models are trained on code. Writing a bar chart, a process diagram, or an infographic in SVG is a code generation task. Writing the same thing as a pixel-based image requires a fundamentally different inference path through a diffusion model. For business graphics, where accuracy of labels and data relationships matters more than photographic realism, the code-generation path produces results that are also more reliable. Diffusion models struggle to render text accurately. SVG contains text as literal readable characters.

This is not a theoretical advantage. Content creators who have used Claude's artifact generation for diagrams, charts, and illustrated data summaries have observed that the output is inspectable, editable, and version-controllable in ways that a PNG or JPEG never is. The SVG file is its own source document.

Search visibility is the argument that enterprise content teams keep ignoring

There is a meaningful crawlability distinction that most digital content strategies have not caught up with. When an SVG is embedded inline in an HTML page, the text content inside that graphic is indexable. A chart label, a category name, a data annotation inside an inline SVG is readable by a search crawler the same way body copy is. The same label inside a PNG or JPEG is invisible to the crawler unless alt text is added, and even then, the crawler reads your description of the image, not the image itself.

For enterprise publications, product documentation, and technical content where charts and diagrams carry substantive information, that distinction affects how much of the page's intellectual content is actually indexed. It also affects how large language models that ingest web content perceive the page. An SVG diagram with labeled axes and annotated findings contributes semantic signal. A PNG of the same diagram contributes nothing without supplementary markup.

The accessibility case runs parallel. SVG supports Web Accessibility Initiative-Accessible Rich Internet Applications, or WAI-ARIA, labels, title elements, and description tags natively. Screen readers can announce what an SVG represents. A raster image requires the same supplementary work SVG handles structurally.

Performance numbers that procurement will not see in the vendor briefing

File size comparisons for simple graphics consistently show SVG outperforming PNG by 60 to 90 percent, with GZip compression extending that advantage further. One test showed an SVG compressed to 621 bytes against a PNG equivalent of 6.33 kilobytes, a 90 percent bandwidth reduction for a single image (Vecta.io, 2018). At page scale, with multiple icons, charts, and diagrams, the cumulative effect on page load time is measurable. Google's Core Web Vitals, which influence search ranking, are directly sensitive to page load performance.

The counterargument, that SVGs are slower than JPEGs for photographic content with complex gradients and continuous tones, is accurate. SVG is not the right format for photography. It is the right format for everything that is not photography: logos, icons, charts, diagrams, infographics, data visualizations, and illustrated findings. That covers the majority of what enterprise content operations actually produce on a weekly basis.

Twenty-five years after the W3C released SVG 1.0, the format has achieved something unusual for a web standard: it has become more relevant, not less.

What changes when your content team can write images

The operational implication of SVG's language model compatibility is underappreciated. A content team that can prompt a language model to produce an SVG chart from a data table, edit the resulting markup to correct a label, and publish without touching a design tool has compressed a multi-step workflow into a single file. That file will render crisply on a 4K monitor, on a phone at 375 pixels wide, and in print at 300 dots per inch, without a separate export for each context.

The assumption embedded in most enterprise content tooling is that visual production requires a design application and a designer. SVG does not eliminate the designer, but it does move more visual production into reach of people who can read and write structured text. Given that language models can now write that structured text on request, the threshold has dropped further.

The question for technology and content leaders is not whether SVG is technically superior for its applicable use cases. The evidence on that is 25 years old. The question is whether their current content workflows are capturing the SEO, accessibility, performance, and cost advantages that SVG already offers, or whether they are generating PNG files, paying for diffusion compute, and wondering why their diagrams do not appear in search results.