CompressPower

Digital Web — Sat, 25 Jul 2026 13:14:25 +0000

Most "compress your image" sites still work the same way: you upload the file, a server does the work, you download the result. For a 4 MB photo that's two network trips and a queue, plus your file sitting on someone else's disk.

You don't need any of it. The browser has shipped everything required for this since about 2012.

The basic version

async function compress(file, quality = 0.8) {
const bitmap = await createImageBitmap(file)
const canvas = new OffscreenCanvas(bitmap.width, bitmap.height)
canvas.getContext('2d').drawImage(bitmap, 0, 0)
return canvas.convertToBlob({ type: 'image/webp', quality })
}

That's the whole thing. createImageBitmap decodes off the main thread, OffscreenCanvas means you can run it in a Worker, and convertToBlob re-encodes at whatever quality you ask for. Ten lines, no dependencies, no server.

Where it gets annoying

Quality is not linear. Going from 0.9 to 0.8 on a JPEG typically saves 30 to 40% of the bytes with almost no visible difference. Going from 0.6 to 0.5 saves maybe 8% and starts putting rings around high contrast edges. If your UI exposes a quality slider, users will drag it to 0.3 and then complain about artifacts.

A target-size loop usually beats a quality slider:

async function compressToTarget(file, maxBytes) {
let lo = 0.4, hi = 0
return best
}

Six binary search steps gets you close enough and runs in well under a second for typical photos.

Canvas strips EXIF. Including orientation. Photos from phones come out rotated and users assume your tool broke them. You have to read the orientation tag before you draw and apply the transform yourself.

Canvas also strips the color profile. Wide gamut images from newer phones get re-tagged as sRGB and come out visibly duller. There's no clean fix in the Canvas path. If this matters you need a WASM encoder like mozjpeg or libwebp compiled with profile preservation.

Alpha channels. Converting a transparent PNG to JPEG gives you a black background unless you fill the canvas white first. Obvious in hindsight, easy to ship as a bug.

Big files kill the tab. A 50 MP image is roughly 200 MB as raw RGBA in memory. Do this on the main thread with three files at once and the tab dies. Worker plus a queue, not Promise.all.

The real argument for client-side

It's not performance, though it is faster. It's that the file never leaves the machine.

If someone is compressing a scanned passport to fit an upload limit, "processed in your browser" is a genuinely different product from "uploaded to our servers and deleted within 24 hours." One of those is a promise. The other is architecture.

A working example if you want to see the pattern in production rather than build it: compresspower.com does image compression, format conversion between JPG, PNG and WebP, and PDF merge and split, all in-browser with no upload step.

Worth opening devtools on the network tab while you use one of these. If you see your file going out over the wire, the privacy copy on the landing page is decorative.

16 states, 16 tax rates: modeling German property transfer tax without hardcoding a mess

Digital Web — Sat, 25 Jul 2026 13:11:23 +0000

If you ever build anything touching German real estate, you will meet Grunderwerbsteuer. It's the property transfer tax, it's set per state, and the rates are not close to each other. Bavaria and Saxony sit at 3.5%. NRW, Brandenburg, Saarland, Schleswig-Holstein and Thuringia sit at 6.5%. The rest land somewhere in between.

On a 400,000 euro apartment that's 14,000 versus 26,000. Same transaction, 12,000 euro difference, decided by a line on a map.

The trap: treating rates as constants

The obvious first move is a lookup object:

const GRUNDERWERBSTEUER = { BY: 0.035, NW: 0.065, /* ... */ }

This is wrong within about a year, and wrong in a way that produces silently incorrect historical data. States change these rates, and they've each changed several times since the power was devolved in 2006. If a user saved an analysis two years ago and reopens it, recalculating with today's rate gives them a number that never existed.

Rates are time-scoped facts, not constants:

type RatePeriod = { from: string; to: string | null; rate: number }

const RATES: Record = {
HH: [
{ from: '2009-01-01', to: '2022-12-31', rate: 0.045 },
{ from: '2023-01-01', to: null, rate: 0.055 },
],
// ...
}

function rateAt(state: StateCode, date: string) {
const p = RATES[state].find(r => date >= r.from && (!r.to || date <= r.to))
if (!p) throw new Error(no rate for ${state} at ${date})
return p.rate
}

Every saved analysis stores its own date. Recalculation is then deterministic and reproducible, which is the whole point if anyone is making a six-figure decision off your output.

Money in floats

0.1 + 0.2 // 0.30000000000000004

You know this. It still shows up, usually as a total that's off by one cent from the sum of its parts, and a user who notices it stops trusting every other number on the page. Integer cents internally, format at the boundary. Intl.NumberFormat('de-DE', { style: 'currency', currency: 'EUR' }) for output.

The part that's actually hard

Transfer tax is the easy input. The hard part is that "yield" has no single definition. Bruttomietrendite uses the asking price. Nettomietrendite uses the total acquisition cost including all Kaufnebenkosten. These differ by 10 to 15%, and listing portals quote the flattering one.

Then cashflow needs annuity amortization with a split between interest and principal, non-recoverable operating costs, a maintenance reserve, vacancy assumption, and AfA depreciation which itself depends on the building's construction year. Every one of those is a defensible assumption with a wide range, and the output is extremely sensitive to all of them.

Which means the interesting design question is not the math. It's whether you show your assumptions. A calculator that returns "5.4% yield" with hidden defaults is worse than useless, because it looks authoritative. A calculator that shows the vacancy rate and maintenance reserve it used, and lets you change them, is a tool.

If you want to see it built out rather than build it yourself, https://www.investbud.de/ does this for German property, with the per-state transfer tax applied automatically and the cashflow broken down monthly and annually.

Financial calculators are a good exercise, by the way. They look like CRUD and they're mostly domain modeling, which is the part most side projects let you skip.

DEV Community: Digital Web

CompressPower

16 states, 16 tax rates: modeling German property transfer tax without hardcoding a mess