That $2.57 domain renews at $43.77: check the renewal price before you register

AlonDrilich — Mon, 09 Nov 2026 21:33:28 +0000

You find a good name for a side project. The registrar shows .store for $2.57, you register it, and a year later the renewal email says $43.77.

Nothing went wrong. Many extensions are priced this way on purpose: a low first year to get the registration, and the real price from year two. The renewal price is published, but checkout pages put the first-year price front and centre.

How big the gap is

I keep a weekly snapshot of one registrar's public list prices (Porkbun) for 532 extensions. In the snapshot from 9 November 2026:

309 of the 532 extensions renew at 2× their first-year price or more.
188 renew at 5× or more.

The first year tells you little about what a name costs to keep. Here are five years of ownership (first year plus four renewals) for some extensions developers often buy:

Extension	First year	Renewal	5 years
.xyz	$2.04	$14.21	$58.88
.com	$11.81	$11.81	$59.05
.dev	$8.75	$12.87	$60.23
.app	$8.75	$14.93	$68.47
.online	$1.96	$28.84	$117.32
.shop	$2.06	$31.41	$127.70
.co	$15.76	$31.20	$140.56
.store	$2.57	$43.77	$177.65
.tech	$6.99	$50.98	$210.91
.io	$28.12	$51.80	$235.32
.ai	$82.70	$82.70	$413.50

.online costs less than .com in year one and about twice as much over five years. .ai is expensive from day one, but at least it doesn't change.

These are one registrar's list prices on one date, in USD. Other registrars price differently, and promotions change often, so treat the table as a reason to check rather than as a quote.

Check it yourself in a few lines

Porkbun publishes its prices at an endpoint that needs no API key. This prints the extensions whose renewal is at least five times the first year:

const res = await fetch("https://api.porkbun.com/api/json/v3/pricing/get", {
  method: "POST",
  headers: { "content-type": "application/json" },
  body: "{}",
});
const { pricing } = await res.json();

const rows = Object.entries(pricing)
  .map(([tld, p]) => ({
    tld,
    first: Number(p.registration),
    renewal: Number(p.renewal),
  }))
  .filter((r) => r.first > 0 && r.renewal / r.first >= 5)
  .sort((a, b) => b.renewal / b.first - a.renewal / a.first);

console.table(rows.slice(0, 20));

It runs in Node 18+ (save it as an .mjs file) or in the browser console.

Before you register

Look for the renewal price, not just the first-year price. Most registrars list both on their pricing page.
Multiply it out over the years you expect to keep the name.
If you're choosing between two extensions, compare the renewals. The cheaper first year often turns out to be the dearer domain.

The full table for all 532 extensions, updated weekly, is on GitHub as CSV under CC BY 4.0: AlonDrilich/tld-renewal-prices (DOI 10.5281/zenodo.24082643). There's also a sortable version at namesale.store/renewal-prices.

Not affiliated with Porkbun. Its endpoint is simply the easiest public source to snapshot.

Why your pdf-lib signature lands in the wrong place on scanned PDFs

AlonDrilich — Mon, 09 Nov 2026 21:28:33 +0000

You render a PDF with pdf.js, let the user click where the signature goes, and draw it with pdf-lib. It works on every test file you have. Then someone uploads a scan, and the signature shows up sideways, in the wrong corner, or off the page.

The bug is almost never in your click handling. It comes from two coordinate systems that agree on ordinary pages and disagree on the ones that come from scanners.

Two coordinate systems

What pdf-lib draws in. page.drawImage() and friends work in the page's raw user space. The origin is at the bottom-left of the MediaBox, y points up, and the page's /Rotate entry is ignored.

What the user sees. A viewer, pdf.js included, shows the CropBox (the visible part of the page), turned by /Rotate, with the origin at the top-left and y pointing down.

On a plain portrait page with no crop, the difference is a y-flip:

const userY = page.getHeight() - viewY;

That's the line most tutorials give you. It's correct until one of these shows up:

/Rotate 90 (or 180, 270). Scanners often store a landscape page as portrait pixels plus a rotate flag. The viewer turns it. pdf-lib doesn't, so your x and y axes are swapped, and the image is drawn rotated relative to what the user saw.
A CropBox smaller than the MediaBox. The viewer shows only the crop. Your click coordinates are relative to the crop's corner, but pdf-lib measures from the MediaBox corner, so everything is shifted.
Both at once. That's common in real scanned contracts.

The mapping

For a point in view space (points, top-left origin, y down) on a page whose visible box starts at (bx, by) and is bw × bh points:

`/Rotate`	user-space x	user-space y
0	`bx + vx`	`by + bh - vy`
90	`bx + vy`	`by + vx`
180	`bx + bw - vx`	`by + vy`
270	`bx + bw - vy`	`by + bh - vx`

The displayed width and height also swap for 90 and 270. Drawing an image upright means passing the matching rotation to pdf-lib, and accounting for the fact that pdf-lib rotates around the image's own origin, not its centre. That last part is where most hand-rolled fixes break.

One more edge case: pdf.js treats a /Rotate value that isn't a multiple of 90 as 0. Do the same, or your output won't match what the user saw.

A small library for it

I pulled this logic into pdf-view-coords, a small MIT TypeScript helper for pdf-lib. You stay in view space, and it does the translation:

import { PDFDocument } from "pdf-lib";
import { viewport, drawImageInView, rectFromFractions } from "pdf-view-coords";

const pdf = await PDFDocument.load(bytes);
const page = pdf.getPage(0);
const png = await pdf.embedPng(signaturePng);

// The box the user drew, as fractions of the rendered page size.
const vp = viewport(page);
const rect = rectFromFractions(vp, { x: 0.1, y: 0.8, width: 0.3, height: 0.08 });

drawImageInView(page, png, rect); // right place, upright, aspect ratio kept

viewport(page) also gives you toUser(x, y) and toView(x, y) if you'd rather draw yourself. The tests check every rotation, with and without a crop, and confirm that the area pdf-lib actually paints matches the view-space rectangle you asked for.

The live demo runs in the browser. Load your own PDF, click on a rotated page, and compare where plain pdf-lib puts the box with where the library puts it.

Install it from GitHub for now:

npm install github:AlonDrilich/pdf-view-coords pdf-lib

If you've hit a PDF where it still lands wrong, open an issue with the file. Odd real-world PDFs are exactly what it needs to be tested against.

DEV Community: AlonDrilich