1998: Two Proposals, One Web
The history of SVG begins with a classic standardization conflict. In April 1998, two camps submitted competing proposals to the W3C for an XML-based vector format. Adobe, Sun and Netscape had jointly designed PGML (Precision Graphics Markup Language) — an XML syntax heavily inspired by the PostScript model that carried on Adobe's professional graphics tradition. Microsoft, Macromedia, HP and Visio, on the other hand, put VML (Vector Markup Language) on the table — more pragmatic, closer to office applications, and deliberately kept simple.
The W3C declined to adopt either proposal directly and instead convened its own working group to synthesize a new format from both sources. It was chaired by Chris Lilley, technical director of the W3C's graphics activity. Out of that mediation came SVG (Scalable Vector Graphics) — neither a pure Adobe format nor a pure Microsoft format, but a compromise that bought out the proprietary claims of everyone involved.
2001: SVG 1.0 Becomes a Standard
It took three full years for the competing proposals to turn into a finished specification. On September 4, 2001, the W3C ratified SVG 1.0 as an official Recommendation. The format brought four structural properties that would later cement its dominance: text-based XML (readable in any text editor, indexable by search engines), resolution independence (renders pixel-perfect at any size), embedding in HTML (no browser plugin required) and a DOM-capable animation model that would go on to shape web animation.
A subtle strength: SVG has been programmatically manipulable from the start. Every element is a DOM node, every attribute accessible via JavaScript. That made SVG the natural foundation for data-visualization libraries like D3.js (2011), and it's the reason virtually every charting tool today (Highcharts, Recharts, Chart.js with an SVG renderer) is built on SVG.
2001–2010: The Long Shadow of Internet Explorer
Despite standardization, SVG remained a niche format for a decade — and that was solely down to Microsoft's refusal. Internet Explorer 6, 7 and 8 simply don't render SVG. Anyone who wanted to use SVG on the web in the early 2000s needed the proprietary Adobe SVG Viewer plugin (which Adobe discontinued in 2009) or fell back on Microsoft's in-house VML — ironically the very format that had actually lost the PGML fight.
It wasn't until Internet Explorer 9 (2011) that native SVG support arrived. After a ten-year wait, SVG had finally reached every mainstream browser. That delay is the main reason SVG's real web comeback only began in 2012 — right on time for the Retina display wave, which demanded exactly what SVG offered structurally: crisp rendering at any resolution.
SVG and the Retina Revolution (2012–2015)
In 2012, Apple shipped the MacBook Pro with a Retina display; a year later iPads and iPhones followed in the same style. Suddenly, web images designed for 96-dpi displays rendered visibly blurry. The usual fix — serving PNGs in several sizes via srcset — worked for photos, but for UI icons and logos SVG was structurally superior. A single 2 KB SVG replaced five PNG variants, dynamic color changes via CSS were possible, and the browser cache only had to be filled once.
From 2014 on, UI libraries (Bootstrap 4, Material Design Icons) began replacing their PNG sprite sheets with SVG symbol sets. By 2018, SVG was the de facto standard for icons and logos. Our SVG vs. PNG vs. JPG comparison for icons covers the modern practice.
The SVG 2 Drama (2012–2018)
While SVG flourished technically, its specification development ran into a dead end. The working group had set out to build SVG 2 — a modernized, cleaned-up version with Web Animations API integration, simplified path commands, and tighter HTML5 integration. What began as a two-year refinement dragged on for six. Along the way, features were added, dropped, modified and dropped again — a classic W3C "boil-the-ocean" project.
In the meantime, browser vendors shipped their own features without spec consensus. The result: SVG 2 was published as a Candidate Recommendation in 2024, but no browser implements it fully. The "SVG" used in practice is a mix of SVG 1.1 plus pragmatic browser extensions. The spec world still hasn't caught up — and that continues to occupy SVG tooling developers to this day.
Tooling: Inkscape, SVGO, Figma
Three tools have shaped the SVG ecosystem for two decades. Inkscape (2003, GPL-licensed) is the most important open-source SVG authoring software, forked from Sodipodi and — since version 1.0 (2020) — mature enough for professional workflows. SVGO (2012, Node.js) is the standard optimizer, stripping out unnecessary editor metadata, whitespace and numeric precision — typically cutting size by 40–70%. Figma (2016) made SVG export from the design tool a given and today sets the expectation for what "clean SVG" looks like.
Our SVG optimization article explains the practical SVGO pipeline and shows what typical Figma exports can throw away without a single pixel looking different.
2020–2026: Lottie, Variable Color Fonts, and SVG as a Fallback
With the rise of Lottie (Airbnb, 2015, JSON-based After Effects animations) and variable color fonts (COLR/CPAL for emoji and colored icons), SVG has picked up competition in a few niches. Lottie is more efficient for complex animations; color fonts deliver UI icons as type, which saves on DOM overhead. But SVG remains structurally unchallenged for static vectors, interactive charts, and anything embedded directly into the HTML DOM.
SVG is enjoying a second revival thanks to server-side rendering: platforms like Next.js (see our note in the Icon Studio article) inline SVG icons directly into the HTML stream, which saves extra round trips and improves First Contentful Paint — relevant for Core Web Vitals.
When SVG Is the Right Choice
- Logos and brand marks. Resolution-independent, recolorable in CSS, a single asset for every size.
- UI icons. Structurally superior here too — see the four react-icons collections bundled into our Icon Studio.
- Charts and data visualizations. DOM-accessible axes, points and lines that can be animated via JavaScript.
- Maps and geodata. Tools like D3.js and Mapbox GL use SVG for overlay layers.
- Print workflows. SVG converts losslessly to PDF and slots into print pipelines — see SVG to PNG for raster conversion.
When SVG is the wrong choice: for photos (pointless — raster wins structurally), for extremely complex paths (10,000+ Bézier points create DOM overhead), and for animations that need more than simple transitions (Lottie is more efficient there).
Sources
W3C SVG 1.1 (Second Edition) Recommendation · W3C SVG 2 Candidate Recommendation · W3C PGML submission (1998) · W3C VML submission (1998) · SVGO project · Inkscape project page · Chris Lilley, "A Brief History of SVG", W3C blog, 2011.