Make og:image work for SVG: pasted markup, svg: payloads, and UTF-8

[alcor]

Makes og:image work for SVG. Two independent bugs, both of which meant links got no preview image at all.

Bug 1 — the rasterizer was never reachable

metadata.js built its rasterizer URL as a path:

info.i = "/.netlify/functions/rasterize/" + info.i;

This repo has never contained a rasterize.js. And in the repo that does (itty-bitty), that function reads event.rawQuery — never the path — so a path-shaped call could not have worked either. Probed against production using itty-bitty's copy:

URL form	Result
/.netlify/functions/rasterize/svg:<b64> — as this code built it	502
/.netlify/functions/rasterize?<b64> — as the function reads it	200 image/jpeg, 8707 bytes

Now points at the shared og-svg renderer with the payload as a query parameter.

Bug 2 — pasted SVG bypassed the renderer entirely

This is the bigger one, because it was the default path rather than an edge case.

The editor invites SVG code — prompt("Choose an emoji, image URL or SVG code") — and then base64s whatever it is given, with no svg: marker:

if (data.image) path.push("i/" + encodeURIComponent(btoa(data.image).replace(/=/g, "")));

metadata.js only routed to the renderer on an explicit svg: prefix. After decodeURL base64-decoded the value, a pasted SVG was raw markup, matched no branch, and fell through to the bare-hostname case:

og:image = "https://<svg xmlns=\"http://www.w3.org/2000/svg\" width=\"600\"…"

resolveImageUrl now detects markup directly, so all three shapes reach the renderer: pasted markup, an explicit svg: payload, and a bare fragment (og-svg wraps fragments in an <svg> root with a 1200×630 viewport).

It is extracted as a pure exported function so the branching is testable — the handler just calls it.

Bug 3 — UTF-8 was mangled

Found only by rendering against the live service; the unit tests were passing.

btoa is Latin-1 only. An accented character encoded as a raw 0xE9 byte that is not valid UTF-8, so resvg rejected the whole document with a 422. Anything above U+00FF — an emoji, a checkmark — made btoa throw outright before the URL was even built.

The editor now uses a UTF-8-safe encoder, and decodeURL recovers UTF-8 with a fallback to the raw bytes, so links written by the old editor still resolve.

Verified

Every shape, through the editor's real encode path, against the live renderer:

Input	Before	After
Pasted full SVG	https://<svg…	200 PNG 600×315
Bare fragment	https://<circle…	200 PNG 1200×630
Accented text	422	200 PNG 400×200
Emoji / ✓	btoa throws	200 PNG 400×200
svg: prefixed payload	502	200 PNG
Absolute URL, relative path, bare hostname	unchanged	unchanged

Tests

Adds vitest and 14 tests. The repo had none.

Worth noting the unit tests alone did not catch the UTF-8 bug — it surfaced only when the end-to-end check against the live renderer disagreed with a green suite. The encoding boundaries are where this code breaks, so the tests now pin them explicitly, including a case asserting that Latin-1 payloads from the old editor still work.

Note on output format

og-svg returns PNG; the old rasterizer produced JPEG. Since no caller ever reached it successfully there is no existing behaviour to preserve, and every crawler accepts PNG.

RENDER_ORIGIN is a single exported constant, so moving og-svg to a dedicated domain later is a one-line change.

🤖 Generated with Claude Code