SVGs on the Web — Aditya Pola

a brief history of web images

The first image format the web broadly supported was GIF, introduced in 1987. It worked, but could only represent 256 colors at once, which made it fine for simple graphics and terrible for photographs. More usefully, it supported multiple frames, which is how GIFs became synonymous with short looping animations decades later.

JPEG arrived in 1992, built for photographs. Its compression algorithm is lossy: it discards detail the eye is least likely to notice, and it is very good at it. A photograph at 90% JPEG quality looks nearly indistinguishable from the original at a fraction of the size. But that same algorithm is catastrophic for line art, text, and sharp-edged graphics. When you compress a screenshot of code as a JPEG, blocky artifacts appear around every character edge.

PNG landed in 1996 as a response to both: lossless compression, full color support, transparency. It became the default for screenshots, icons, and logos: anything that needed crispness and was not a photograph.

WebP and AVIF are modern successors that squeeze more compression out of raster images than JPEG or PNG. Still useful, still fundamentally the same thing underneath: a grid of colored pixels at a fixed resolution. Scale any of them up and you’re just making the pixels bigger.

why SVG is different

SVG stands for Scalable Vector Graphics. It does not describe pixels; it describes instructions. Draw a line from here to there. Fill this enclosed shape. Use this color. The browser calculates what pixels to actually draw at display time, at whatever resolution it needs.

Scale an SVG icon to any size and it stays sharp. A 48×48 viewbox drawn at 4K is still perfectly crisp; the browser re-rasterises the instructions fresh at full resolution.

SVG files are plain text: XML, specifically. That makes them readable, editable without special software, diffable in git, and often tiny. A simple icon is maybe 200–400 bytes. You can paste the whole thing directly into HTML and it renders inline, no network request required.

Most importantly for this site: SVG elements are styleable with CSS. Setting stroke="currentColor" on an SVG means its lines inherit whatever color is set on the parent element. The four page icons here automatically follow the active theme, with the same markup rendering differently depending on whether you are in light, dark, or live mode.

how SVG paths work

Most SVG shapes have dedicated elements: <circle>, <rect>, <line>. The powerful one is <path>, which describes an arbitrary shape through a sequence of drawing commands packed into the d attribute.

The commands read like instructions to a pen on paper:

M x y — move the pen to a point without drawing anything
L x y — draw a line to a point
C x1 y1, x2 y2, x y — draw a cubic bezier curve to (x,y), pulled by two control points
Z — close the path back to the starting point

A typical hand-drawn shape uses almost entirely C commands. The six numbers in a cubic bezier are the two control point handles; the further they sit from the endpoints, the more dramatic the curve’s bend. Getting an intuition for how control points influence a curve is most of what it takes to hand-write SVG paths.

All coordinates live inside the coordinate system defined by viewBox. viewBox="0 0 48 48" sets the canvas from (0,0) at the top-left to (48,48) at the bottom-right. The browser maps that space to whatever pixel size the element is on screen.

the icons

Every section of this site has a small hand-drawn icon in the top-right corner of its page. They were written as path coordinates directly, with no design tool, no export step, and no tracing. The slight imprecision is intentional: control points placed a little off from where a geometrically exact shape would put them give the curves their hand-drawn quality.

The icons are defined once in a shared data file and referenced wherever they appear, in each section’s page header and in the gallery below. Eight are drawn at the time of writing, two per section; more may be added.