Spent a morning debugging why generated OG cards looked subtly wrong: the title was rendered, then re-rendered a few pixels lower in a different weight, like a bad photocopy. Turned out my text-measurement pass and my draw pass disagreed about which font file actually loaded. The title string fit comfortably in the 60-char cap, so nothing about the input looked suspicious. But the measurement pass used the primary font's metrics while the draw pass silently fell back to a system default when the webfont hadn't finished hydrating. Two different fonts, two different line heights, and a card that looked fine at a glance but failed the "does this look like our brand?" test every time. The fix wasn't clever. I made the renderer wait for the font to actually load before measuring, and I added a guard that refuses to draw if the loaded font's family name doesn't match what was requested. If it can't confirm the font, it fails the render loudly instead of sh...

I built an OG image API that takes a title + description and renders a 1200x630 card. It worked great in my tests. Then I wired it into a link-unfurling pipeline for an agent that posts dozens of links into Slack channels, and suddenly a third of the previews came back gray. The bug wasn't in the renderer. It was in the CDN I put in front of it. Every generated image URL looked like /og?title=...&desc=... . The CDN cached on the full URL, which is correct — except Slack's unfurling bot strips query strings before requesting the image in some clients. So ?title=Deploy+failed and ?title=Deploy+succeeded both collapsed to /og/ , and the first response got cached for everyone else. One "Deploy failed" card got served to a channel full of "Deploy succeeded" links. The fix was boring and effective: hash the full parameter set into the path itself ( /og/a3f9c2….png ) and make the query string optional. Cache key and content now agree. What I actually le...

Last month a few of my social preview cards started rendering in the wrong font. I generate Open Graph images from a title and description on a 1200x630 template, and the cards are supposed to use a specific display font. Some of them came out in the fallback serif instead — no errors, no warnings, just wrong-looking text. The pattern was the clue: it only happened on the first render after a deploy, or in a cold container. Locally, everything was perfect. That smelled like caching, and it was — browser font caching, not mine. The generator renders an HTML template in headless Chromium and screenshots it. My code did goto(url) followed by screenshot() as fast as possible. On my dev box the woff2 was already in Chromium's disk cache, so it loaded "instantly." In a fresh container, the font had to travel from the font host, taking anywhere from 200 to 800ms — and Chromium helpfully paints with a fallback font while it waits. My screenshot never waited. I was shipping a...

When I built an OG image generator — POST a title and description, get back a 1200x630 social-card PNG — the first render looked perfect. The second, a ~90-character title about database indexing, ran clean off the right edge and clipped mid-word. The root cause was embarrassing: Canvas's fillText() doesn't wrap. Ever. It draws one line and happily paints 3,000px of text onto a 1,200px image. Browsers wrap HTML; canvas is a paint API, not a layout engine. If you want wrapped text, you build the line-breaking logic yourself. What ended up being the real core of the product: 1. Measure, never estimate. Every word's width comes from ctx.measureText(). My first heuristic (average character width × length) broke instantly on ALL-CAPS titles and wide glyphs. 2. Greedy line packing against the safe area: 1200px minus 64px padding per side = 1072px usable. Append a word; overflow means a new line. 3. Cap at three lines with an ellipsis — but only append "…" if the last...