DEV Community: Jonas Hämmerle

Stop rolling your own password breach checker — here's how k-anonymity makes it safe

Jonas Hämmerle — Tue, 11 Aug 2026 10:09:20 +0000

If you're checking user passwords against HaveIBeenPwned's breach database, please don't send the full password (or even the full hash) over the wire. Here's why, and the actual protocol that fixes it.

HIBP's Pwned Passwords API uses k-anonymity: you SHA-1 hash the password locally, send only the first 5 characters of the hash, and the API returns every suffix that starts with that prefix (usually 300-900 of them). You compare locally. The full password never leaves your server, and HIBP never sees enough to reconstruct it.

import { createHash } from "node:crypto";

async function isBreached(password) {
  const hash = createHash("sha1").update(password).digest("hex").toUpperCase();
  const prefix = hash.slice(0, 5);
  const suffix = hash.slice(5);
  const res = await fetch(`https://api.pwnedpasswords.com/range/${prefix}`);
  const text = await res.text();
  return text.split("\n").some(line => line.startsWith(suffix));
}

That's genuinely all it takes — no library needed. I wrapped this (plus password strength scoring) into an endpoint on Validate if you'd rather not maintain the hashing/comparison logic yourself, but honestly, the snippet above will get most people there. Sibling APIs on the same account: QR API and Currency API.

ISO 4217 currency codes: the edge cases that break naive multi-currency forms

Jonas Hämmerle — Sat, 08 Aug 2026 10:02:11 +0000

Most currency handling code assumes every currency has 2 decimal places and a straightforward numeric amount. Neither assumption holds universally, and both break in ways that are easy to miss until a real transaction hits the edge case.

Not every currency has 2 minor units. JPY has zero — ¥100 is a whole number, there's no ¥100.00. KWD (Kuwaiti Dinar) has three. If your form/database column hardcodes 2 decimal places "because that's how currency works," you'll either round JPY amounts into nonsense or truncate KWD precision.

const MINOR_UNITS = { JPY: 0, KWD: 3 /* ... */ }; // default 2 for anything not listed
function formatAmount(amount, code) {
  const digits = MINOR_UNITS[code] ?? 2;
  return amount.toFixed(digits);
}

Currency codes aren't a stable, closed set forever — they get added, and in rare cases retired (old Eurozone currencies like DEM, FRF were withdrawn when the Euro launched). A hardcoded currency list baked into your app years ago can silently drift from reality. Pull the supported-currency list from a source that's actually kept current, rather than a list you typed once.

Symbol collisions are a UI bug waiting to happen. $ alone is ambiguous across USD, CAD, AUD, and several others — showing just the symbol without the ISO code next to it (or as a tooltip) is a real source of "wait, is that dollars or my dollars" confusion in any multi-currency UI.

Currency API's /v1/currencies endpoint always reflects the actual current supported set (ECB scope, ~30 major currencies) rather than a list that can go stale — check it instead of hardcoding one, especially if you're validating currency-code input from a form. Sibling API QR API is useful if that same form flow ever needs a QR code for a payment link, and Validate covers the rest of the form's IBAN/email/phone checks.

The IBAN mod-97 checksum, explained (and how to validate one in one line)

Jonas Hämmerle — Tue, 04 Aug 2026 16:28:32 +0000

Ever wondered how your bank instantly knows you fat-fingered an IBAN before it even checks if the account exists? It's a checksum: ISO 13616's mod-97 algorithm.

Here's the short version: move the first four characters to the end, convert letters to numbers (A=10, B=11...), then check if the resulting number mod 97 equals 1. That's it — no database lookup needed to catch most typos.

// simplified version of the check
function ibanChecksumValid(iban) {
  const rearranged = iban.slice(4) + iban.slice(0, 4);
  const numeric = rearranged.replace(/[A-Z]/g, c => c.charCodeAt(0) - 55);
  let remainder = 0;
  for (const digit of numeric) remainder = (remainder * 10 + Number(digit)) % 97;
  return remainder === 1;
}

Fine for a side project. Once you're validating IBANs from real users, you also want country-specific length checks, BBAN structure validation, and ideally a formatted, human-readable output — which is more code than you want to own for something this boilerplate.

If you'd rather not maintain that: Validate is a small API I built that handles this (plus VAT/email/phone/credit-card format checks) as a single JSON call. Free tier is 100 requests/month, no card required. Same account also runs QR API (QR code generation) and Currency API (exchange rates) if useful.

Caching exchange rates correctly: per-day TTL, not per-request memoization

Jonas Hämmerle — Sat, 01 Aug 2026 12:41:30 +0000

If you're converting to several currencies at once — a pricing page showing a product in 8 currencies, say — the naive approach is one /convert call per currency pair. That works, but it's leaving an easy optimization on the table: ECB-sourced rates update once per business day, so there's no reason to be making fresh network calls more often than that.

The right cache key isn't "this specific conversion," it's "the rate table for this base currency, as of today's date":

const rateCache = new Map(); // key: `${base}:${isoDate}`

async function getRatesForDay(base) {
  const today = new Date().toISOString().slice(0, 10);
  const key = `${base}:${today}`;
  if (rateCache.has(key)) return rateCache.get(key);

  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/rates?base=${base}`, {
    headers: { "X-RapidAPI-Key": key_env, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  const data = await res.json();
  rateCache.set(key, data);
  return data;
}

One call per base currency per day gets you every target currency's rate in that response — /v1/rates returns the full table, not just one pair — so converting to 8 currencies from a cached table is 8 in-memory lookups, not 8 network round-trips.

Two things worth being careful about: cache the date the rate was published, not the date you fetched it (a request right after midnight UTC might still be serving yesterday's ECB publish if today's hasn't landed yet), and don't cache across a process restart without also persisting the date key — a stale in-memory cache that outlives its day is exactly the silent-wrong-number problem you're trying to avoid.

Currency API's /v1/rates endpoint is built for this pattern — pull the whole table once, cache it client-side for the day, and reserve /v1/convert for one-off single conversions where pulling the whole table would be overkill. Sibling APIs on the same account: Validate and QR API.

The QR code capacity cliff: why a shortened URL scans more reliably than a long one

Jonas Hämmerle — Thu, 30 Jul 2026 16:01:00 +0000

QR codes don't degrade gracefully as you stuff more data into them — they hit a capacity ceiling per version/error-correction combination, and the module grid gets denser and denser as you approach it. Past a certain point you're not looking at a QR code you can scan from arm's length anymore, you're looking at one that needs to nearly touch the camera lens to resolve.

The numbers, roughly: at the lowest error correction level (L), a QR code tops out around 2,900 alphanumeric characters or ~4,300 numeric-only characters. That sounds like a lot until you remember two things:

Every character costs more space than you'd think, because the encoding also has to carry the error-correction payload alongside your data — that's not overhead you can opt out of, it's the whole point of the format being scannable at all.
Real-world scanning distance matters more than theoretical capacity. A QR code sized for a business card that's encoding near the character ceiling will produce a module grid so fine-grained that a phone camera needs to be uncomfortably close to resolve individual modules.

The fix is almost always: don't encode raw data, encode a short pointer to it. A URL-shortened link, a UUID that looks up a record server-side, a short numeric ID — anything that keeps the encoded payload well under a hundred characters keeps the module grid coarse enough to scan reliably from a normal distance, at a normal print size.

# fine — short, scans easily even printed small
curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://short.link/x7f2" ...

# avoid — encoding a full JSON payload directly makes the grid dense
# and print-size-sensitive for no real benefit over a lookup pointer

If you're building this into a product, cap the accepted input length and fail with a clear error before hitting the encoder's own hard limit — silently truncating someone's data is worse than telling them up front. QR API caps data at 2000 characters for exactly this reason: comfortably under the spec's own ~2900-character ceiling at the lowest ECC level, with a clear 4xx instead of an encoder crash past it. Same account also runs Validate and Currency API.

Validating a CSV of 500 emails or IBANs? Stop doing it one HTTP call at a time

Jonas Hämmerle — Tue, 28 Jul 2026 16:17:15 +0000

Cleaning a signup list or a vendor-payout CSV against a single-item validation endpoint means one HTTP round-trip per row — 500 rows means 500 requests, most of which burn through a rate limit before you're a quarter of the way through the file.

The fix isn't a faster loop, it's an endpoint that accepts the whole array and validates it server-side in one call:

curl -X POST https://validate-api.p.rapidapi.com/v1/batch/iban \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: validate-api.p.rapidapi.com" \
  -H "Content-Type: application/json" \
  -d '{"ibans": ["DE89370400440532013000", "not-an-iban", "FR1420041010050500013M02606"]}'

{"count": 3, "results": [
  {"input": "DE89370400440532013000", "valid": true, "countryCode": "DE", "errors": []},
  {"input": "not-an-iban", "valid": false, "countryCode": null, "errors": ["IBAN contains invalid characters"]},
  {"input": "FR1420041010050500013M02606", "valid": true, "countryCode": "FR", "errors": []}
]}

Same checksum logic as the single-item endpoint, just run once per array item instead of once per request — order-preserving output, so row n in the response always maps to row n in your input.

One design choice worth calling out if you're building something similar: batch email validation defaults MX-record checking to off, unlike the single-item endpoint. A batch of 50 emails with MX checking on means 50 DNS lookups fired from one request — fine occasionally, not something you want as the default for a bulk endpoint. Opt in explicitly (checkMx: true) when you actually need it.

I added /v1/batch/iban (up to 100 items) and /v1/batch/email (up to 50 items) to Validate for exactly this list-cleaning use case — same free tier, no separate pricing for batch. Sibling APIs on the same account: QR API and Currency API.

Why a currency API should return 502, not a stale rate, when the upstream is down

Jonas Hämmerle — Sat, 25 Jul 2026 12:14:15 +0000

A tempting shortcut when your rate source is unreachable: serve the last cached rate and let the request succeed. For most APIs that's a reasonable degradation strategy. For anything touching money, it's the wrong default.

The problem isn't that a stale rate is wrong — it's that a stale rate looks identical to a correct one from the caller's side. A 200 response with a slightly-off number is far more dangerous than an honest failure, because nothing downstream knows to treat the value with suspicion. A checkout flow that silently converts at yesterday's rate doesn't fail loudly; it just quietly overcharges or undercharges, and nobody notices until a reconciliation problem shows up much later.

async function getRateOrFail(base, target) {
  try {
    const res = await fetch(upstreamUrl(base, target));
    if (!res.ok) throw new Error(`upstream returned ${res.status}`);
    return await res.json();
  } catch (err) {
    // Explicit failure, not a stale fallback — the caller needs to know
    // "we don't have a trustworthy number right now," not get a wrong one.
    throw new UpstreamError(err);
  }
}

The tradeoff this makes explicit: you're accepting worse availability (a 502 during an upstream outage) in exchange for a hard guarantee that every successful response is a real, current-as-of-its-timestamp rate — never a guess dressed up as data.

This is the one place Currency API's "no fabricated data" principle gets tested in practice: if Frankfurter (the ECB rate proxy it uses) is unreachable, the API returns a clean 502 upstream_error instead of quietly serving whatever it last had cached. Same principle sibling API Validate applies to its VIES/MX lookups — fail honestly rather than silently degrade on anything where the caller can't tell the difference between fresh and stale. Third sibling API on the same account: QR API.

SVG output for QR codes: why vector beats raster once anyone screenshots or resizes it

Jonas Hämmerle — Thu, 23 Jul 2026 16:03:27 +0000

Raster QR codes (PNG/JPEG) look fine at the size they were generated for and fall apart the moment someone resizes, screenshots, or prints them larger — the module edges blur, and blurred module edges are exactly what breaks a decoder's ability to read the grid.

SVG sidesteps this completely because a QR code is fundamentally vector data already — it's a grid of black/white squares, not a photograph. Rendering it as <rect> elements instead of a pixel bitmap means it stays crisp at any zoom level, print size, or screen density:

<img src="qr.svg" alt="Scan to open" width="600" />

That's a 600px display of a code that could've been generated at any size — no upscaling artifacts, because there was never a fixed pixel grid to begin with.

A couple of practical notes if you're embedding these in a product:

Inline the SVG (rather than referencing it as an <img src>) if you need to style fill colors with CSS at render time instead of baking colors in server-side.
Strict hex validation on any color params matters more than it looks — if a QR generation endpoint lets you pass custom foreground/background colors and embeds them directly into SVG attributes, that's an injection surface if the values aren't validated as actual hex colors first.
Raw matrix output is still useful — for canvas rendering, terminal output, or anything that isn't "embed an image," getting the boolean module grid directly beats parsing an SVG back into pixels.

QR API returns image/svg+xml by default from GET /v1/qr, with a /v1/qr/matrix variant returning the raw grid for exactly that second use case. Sibling APIs on the same account: Validate and Currency API.

ECB reference rates vs live FX feeds: what 'updated once a day' actually costs you

Jonas Hämmerle — Tue, 21 Jul 2026 13:34:59 +0000

Most currency-conversion needs in a typical web app — pricing pages, invoicing, displaying a rough converted total — don't need a tick-by-tick FX feed, but it's worth being explicit about what you're trading away when you use ECB reference rates (published once per business day) instead.

What ECB rates are good for: pricing display, invoicing, order totals shown to a customer, anything where "the rate as of this morning" is an acceptable, disclosed approximation. They're free, stable, and don't require an account.

What they're not good for: FX execution, arbitrage, anything where being a few hours stale has real financial consequences. If you're actually trading currency, not just displaying a converted number, you need a feed that updates far more often than once a day — and probably isn't free.

The practical pattern that works for the first category:

async function getRate(base, target) {
  const res = await fetch(`https://currency-api.p.rapidapi.com/v1/convert?from=${base}&to=${target}`, {
    headers: { "X-RapidAPI-Key": key, "X-RapidAPI-Host": "currency-api.p.rapidapi.com" },
  });
  return res.json(); // { rate, result, date } — "date" tells you exactly how fresh this is
}

The date field matters more than people give it credit for — surfacing "rate as of {date}" next to a converted price, rather than presenting it as live, sets the right expectation and avoids a support ticket when someone notices the number doesn't match what their bank showed them an hour later.

Currency API is built on exactly this tradeoff: ECB reference rates via Frankfurter, free and keyless, explicit about being once-a-day data rather than pretending to be a live feed.

QR code error correction levels: L vs M vs Q vs H, and when the tradeoff is actually worth it

Jonas Hämmerle — Tue, 21 Jul 2026 13:34:55 +0000

Every QR code has a Reed-Solomon error-correction level baked in — L (~7% recovery), M (~15%), Q (~25%), H (~30%) — and picking the wrong one either wastes visual density or leaves you with a code that stops scanning the moment it gets a little damaged.

Here's the actual decision, not just the percentages:

L — clean digital display only (a code shown on a screen, never printed, never overlaid with anything). Smallest, least dense module grid for a given payload.
M — the safe default for most printed material. Handles minor print smudging or a slightly low-quality printer.
Q — printed material that gets handled a lot (product packaging, shipping labels) or is at moderate risk of scuffing.
H — anything with a logo or graphic overlaid on top of the code, since that overlay is itself "damage" the decoder has to recover from. Also the right call for outdoor/weather-exposed prints.

The mistake I see most often: defaulting to H everywhere "to be safe." Higher error correction means more modules for the same data, which means a denser, harder-to-scan-from-a-distance code with zero benefit if nothing's ever going to obscure it. Match the level to the actual damage risk, not to the theoretical maximum.

curl "https://qr-api.p.rapidapi.com/v1/qr?data=https://example.com&ecc=Q" \
  -H "X-RapidAPI-Key: <your-key>" \
  -H "X-RapidAPI-Host: qr-api.p.rapidapi.com" \
  --output qr.svg

QR API exposes ecc as a plain query param (defaults to M) so you can set it per use case instead of hardcoding one level everywhere.

The complete guide to disposable email detection

Jonas Hämmerle — Tue, 21 Jul 2026 13:25:45 +0000

Syntax-valid, MX-record-valid, and still worthless for your product: that's a disposable email address from 10minutemail, guerrillamail, mailinator, or one of several hundred similar throwaway-inbox services. If you're not filtering these, a meaningful slice of your "verified" signups are addresses nobody will ever check twice.

Here's why this is a genuinely different problem from syntax or MX validation, and how to actually solve it.

Why there's no algorithmic tell. A disposable-mail domain looks completely normal — valid syntax, real MX records, sometimes even a legitimate-looking domain name. There's no structural pattern that distinguishes mailinator.com from gmail.com at the protocol level. The only reliable signal is a maintained list of known disposable domains, checked against the domain part of the address:

function isDisposable(email, disposableDomainSet) {
  const domain = email.split("@")[1]?.toLowerCase();
  return disposableDomainSet.has(domain);
}

The catch: the list has to stay current. New disposable-mail domains spin up constantly — some services rotate domains specifically to dodge blocklists. A list you snapshot once and never update degrades within weeks. The community-run disposable-email-domains project is a solid free starting point and is actively maintained, but you need a process to re-sync it, not a one-time import.

Where this fits in the validation pipeline. Order matters, because each check is progressively more expensive and should only run if the previous one passed:

Syntax — near-instant, always run
MX record lookup — one DNS call, catches typo'd/dead domains
Disposable-domain check — a set lookup against your list, catches throwaway-but-technically-valid addresses

Running them in that order means you only pay for the disposable-domain check on addresses that already passed the cheaper filters — no wasted work on obviously broken input.

What it doesn't catch: a user who signs up with a real Gmail address they simply never check again. Disposable-domain detection targets services designed for throwaway use, not general inbox abandonment — that's a retention problem, not a validation one.

I run this exact pipeline (syntax → MX → disposable-domain, each opt-in past the first) as an endpoint on Validate with a synced domain list, if you'd rather not own the re-sync process yourself. Sibling APIs on the same account: QR API and Currency API.

The complete guide to disposable email detection

Jonas Hämmerle — Tue, 14 Jul 2026 12:55:24 +0000

Here's why this is a genuinely different problem from syntax or MX validation, and how to actually solve it.

function isDisposable(email, disposableDomainSet) {
  const domain = email.split("@")[1]?.toLowerCase();
  return disposableDomainSet.has(domain);
}

Where this fits in the validation pipeline. Order matters, because each check is progressively more expensive and should only run if the previous one passed:

Syntax — near-instant, always run
MX record lookup — one DNS call, catches typo'd/dead domains
Disposable-domain check — a set lookup against your list, catches throwaway-but-technically-valid addresses

Running them in that order means you only pay for the disposable-domain check on addresses that already passed the cheaper filters — no wasted work on obviously broken input.