1. Downscaling is not drawImage(width/2) — usually

Rendering a 1024×1024 source at every size from 512 down to 29 is the easy part, but quality varies with technique:

• Single-step scaling from 1024 to 29px in one drawImage call aliases badly — fine detail collapses into moiré.

• Step-down halving (1024→512→256→…→32) preserves edges noticeably better because each step's kernel operates on a sane frequency range.

• Browser imageSmoothingQuality: "high" gets you most of the way; for pixel-crisp small sizes, a sharpening pass at ≤64px recovers the bite that downscaling loses.

2. Windows: a real multi-resolution .ico

The .ico format is a container, not an image. The binary layout:

ICONDIR      (6 bytes)   — reserved, type=1, count
ICONDIRENTRY[n] (16 × n) — width, height, colors, planes, bpp,
                             size, offset for each embedded image
[image 0] .. [image n-1] — BMP or PNG data

Windows picks the closest entry and scales minimally, so a real .ico embeds 16/24/32/48/64/256px members. The classic shortcut — renaming a 256px PNG to .ico — technically loads, but Explorer renders it blurry at every other size, and some shell contexts (taskbar, alt-tab) misbehave. Writing the directory structure with embedded PNGs (PNG allowed for all entries since Vista) is ~50 lines of code and the difference between amateur and professional output.

3. Apple: the 1024 marketing icon hates alpha

The App Store rejects a 1024×1024 icon with an alpha channel. Most source artwork (and every AI-generated icon) has transparency, so a correct pipeline flattens it: composite onto an opaque background, then encode without alpha. The tell that a generator skipped this: your upload "looks fine in the ZIP" and App Store Connect throws ERROR ITMS-90717 a minute later.

The other Apple quirk: browsers cannot emit .icns (it's not a web-supported container), so the honest output is an AppIcon.iconset folder plus the one-liner macOS already ships with:

iconutil -c icns AppIcon.iconset

Xcode's asset catalog needs Contents.json — a JSON array mapping every {idiom, size, scale} triple to a filename. Generate it; hand-writing it is how single-scale entries go missing.

4. Android: adaptive icons live on a different canvas

Since API 26, the launcher icon is not an image, it's a composition: foreground and background layers on a 108×108dp canvas, of which only the central 66dp circle is guaranteed visible. Every OEM mask (circle, squircle, rounded square) crops differently.

Consequences a naive resizer ignores:

• Your logo must fit the safe zone, not the canvas edges — 20.5% of each dimension is crop territory.

• Android 13's themed (monochrome) icons need a third, single-colour layer — typically the foreground's alpha silhouette.

• Legacy densities (mipmap-mdpi … xxxhdpi) still ship for pre-8.0 devices.

• The wiring is mipmap-anydpi-v26/adaptive-icon.xml referencing drawable layers.

A live launcher-mask preview with a safe-zone overlay — showing how much of your logo each mask would crop — turns this from guesswork into a design decision.

5. PWA: maskable is a purpose, not a size

Web app manifests accept purpose: "maskable", where the browser may crop to any shape inside a safe zone (80% of the icon per spec). Shipping only "any" icons is why so many PWAs show a shrunken logo floating in a white circle on Android. A correct export emits both variants and the manifest snippet to use them.

6. Packaging without a server

The whole pipeline — decode, scale, encode, zip — is client-side feasible: Canvas for raster ops, toBlob/WASM for encoding, and a pure-JS ZIP writer streaming the ~40 files into one download. Artwork never leaves the machine, which for unpublished app artwork is a real requirement, not a nice-to-have.

The takeaway: an icon pipeline is 10% resizing and 90% platform archaeology. Get the rules above right once, and "export icons" stops being a pre-release chore.

The document model: layers as data, not pixels

The core decision that makes everything else work: the document is stored as a list of operations, not a flattened bitmap.

A layer is a record:

{
  id: "layer-7",
  type: "image" | "text" | "shape" | "brush" | "adjustment",
  source: canvas | params,
  opacity: 0.0–1.0,
  blendMode: "normal" | "multiply" | "screen" | "overlay" | ...,
  mask: maskCanvas | null,
  visible: true
}

Image layers hold an offscreen canvas. Text, shape, and brush layers hold parameters (string, transform, point arrays). Adjustment layers hold only settings — exposure, contrast, curves — with no pixels of their own.

Because the document is data, edits are reversible by construction. Move a text layer? Change a transform field and re-render. Delete a brush stroke? Splice the stroke list. Nothing is ever "baked in" unless you export.

Compositing: the render loop

Each frame (or on-demand after an edit), the editor composites the stack bottom-up:

function composite(layers, ctx) {
  for (const layer of layers) {
    if (!layer.visible) continue;

    ctx.globalAlpha = layer.opacity;
    ctx.globalCompositeOperation = layer.blendMode;

    let source = resolveSource(layer); // render params → offscreen canvas

    if (layer.mask) {
      // bake mask into a scratch canvas first
      const masked = scratch(layer.width, layer.height);
      masked.draw(source);
      masked.ctx.globalCompositeOperation = "destination-in";
      masked.ctx.drawImage(layer.mask, 0, 0);
      source = masked.canvas;
    }

    ctx.drawImage(source, layer.x, layer.y);
  }
}

Two details carry most of the weight:

Blend modes are native. Canvas 2D's globalCompositeOperation implements the full PDF-12 set — multiply, screen, overlay, soft-light, and friends — with the same per-channel math desktop apps use. There is no need to reimplement blending in JavaScript or WebGL for 8-bit compositing.

Masks are alpha maps. A mask is just another canvas painted in greyscale. Compositing it with destination-in multiplies the layer's alpha by the mask's luminance-encoded alpha — hide-without-deleting semantics, identical to a layer mask in any raster editor.

Non-destructive adjustments

An adjustment layer says "apply these parameters to everything below me at composite time." Implementation options:

1. CSS filter on the draw call — ctx.filter = "brightness(1.2) contrast(0.9)" is GPU-accelerated and covers the common corrections.

2. Pixel passes for anything filter can't express (curves with custom control points) — an ImageData loop or a fragment shader, cached per layer until its parameters change.

Caching matters: every layer renders to its own cached canvas and only re-renders when its inputs change. Editing layer 8 of 12 re-composites the stack (cheap drawImage calls) without re-rendering the untouched sources.

The parts that genuinely needed extra work

HEIC input. Browsers decode JPEG and PNG natively; iPhone HEIC needs a WASM decoder compiled from libheif. It loads lazily — you pay the ~1MB only when an actual HEIC hits the editor.

Modern export formats. canvas.toBlob gives PNG, JPEG, and WebP for free. AVIF and JPEG-XL have no native encoder, so those go through WASM encoders — again loaded on demand.

Local AI background removal. An image-segmentation model runs in-browser (WebGL/WASM inference, no upload). It is the same class of on-device model we benchmarked when comparing client-side background removal approaches — good enough for portraits and product shots, with zero privacy trade-off.

Memory ceilings. Every layer is a full-size RGBA bitmap: a 4000×3000 image costs ~48MB per layer of source data. This is the honest physical limit of in-tab editing — large multi-layer documents belong on desktop hardware, and there is no clever engineering around device RAM.

What stays on the server

Almost nothing, by design. In the ToolsMonk Photo Editor — the production version of this architecture — exactly two features are opt-in server calls: smart crop (sends a downscaled copy) and text-to-image generation (sends the prompt). Open, edit, mask, filter, background-remove, and export all happen on your device, which is the whole point: latency bounded by hardware instead of the network, and client data that never leaves the machine.

The interesting takeaway for anyone building creative browser tools: Canvas 2D got further than most people assume. The platform gap with desktop is no longer compositing math — it's memory and native codecs, and both gaps are narrowing.

The math is one formula — the honesty is in the details

EMI is the standard amortization formula:

function emi(principal, annualRate, months) {
  const r = annualRate / 12 / 100;
  if (r === 0) return principal / months;
  const f = Math.pow(1 + r, months);
  return principal * r * f / (f - 1);
}

Five lines. But a calculator people trust shows more than a number:

• Total interest vs principal split — the first moment most borrowers realize a long loan doubles the cost. Showing the interest share as a percentage is more honest than hiding it below the fold.

• Amortization awareness — prepayment changes the schedule, not just the EMI. Even a simple comparison view ("what if 1 year shorter?") changes how people use the number.

• Currency and locale formatting — the same math reads completely differently across locales. Intl.NumberFormat handles this; hand-rolled string code does not.

UX details that matter more than the formula

Live results as you type. A "Calculate" button is a remnant of server-era thinking. The state is tiny — three numbers — so recompute on every keystroke. Debounce nothing; it's microseconds.

Offline as a feature, not an accident. A calculator has zero server dependency, which means a service worker makes it work on a plane, in a basement, or on a dead connection — exactly when people double-check loan numbers.

"Stays on your device" as a visible promise. People type real salary and loan figures into these boxes. Showing a small, specific indicator that inputs never leave the browser converts a privacy policy into a UI fact.

Why client-side is the only right answer here

There is no model, no file, no heavy compute — so a backend adds latency, cost, and a privacy question for zero benefit. Everything the calculator does fits in one function call. The interesting engineering is presentation: charts for the principal/interest split, sane number formatting, and accessible input semantics.

I build these as part of ToolsMonk — a free suite of 255+ browser tools where the EMI calculator (with payment-breakdown charts, comparison view and multi-currency support), SIP, stock and depreciation calculators all run entirely client-side, on the web and inside the Windows and Android apps.

Takeaways for your own calculators

• The formula is commodity; the trust details (breakdown, formatting, live updates) are the product.

• Ship it offline — a calculator that needs the network is a widget that chose to be worse.

• Show the interest share prominently. Users reward honesty with return visits.

What do you look for in a financial calculator before you trust the number?

The model that changed things

The workhorse behind in-browser background removal is a class of lightweight segmentation models — U^2-Net derivatives and MobileNet-based variants — exported to ONNX and executed with ONNX Runtime Web (or TensorFlow.js) on WebAssembly. A quantized model lands around 40-80 MB, downloads once, and is cached by the browser afterwards.

The pipeline is short:

1. Decode the image to an offscreen canvas, downscale to the model's input size (typically 320x320).

2. Normalize pixel values to the model's expected range and run inference — a segmentation mask comes out as a grayscale alpha map.

3. Upscale the mask back to full resolution, feather the edges (a small blur on the alpha channel), and composite: original RGB + mask as alpha = cutout PNG.

Step 3 is pure canvas work. The only "AI" is step 2, and it runs on the user's CPU — or GPU, if WebGPU is available.

Why WebAssembly threads needed a header (the fragile part)

WASM inference is 2-6x faster with threads, and threads require the page to be cross-origin isolated — the COOP/COEP header pair. COEP: credentialless was the pragmatic choice for us because the strict variant (require-corp) breaks every third-party image and CDN script that does not send CORP headers.

The failure modes are invisible: a missing COEP header on one worker route kills SharedArrayBuffer with an empty console error, and the fix is a route pattern that exactly matches your worker paths. This class of deployment bug is the real cost of client-side ML — the model is easy, the headers are not.

Where client-side segmentation still loses to servers

Honest assessment, because the trade-offs matter:

• Hair and fur edges — server models with matting refinement still produce cleaner alpha than a 320px-mask upscaled to 4000px. Feathering hides it at social-media sizes, not in print.

• Very large images — decoding a 10000x10000px photo into a canvas can allocate hundreds of MB; tiling strategies help but add complexity.

• Speed on old hardware — a 2015 laptop without WASM threads will wait several seconds; the same image on a server GPU is sub-second.

The compensating advantage is architectural: the image never leaves the device. For personal photos, ID scans, and client assets, that is not a feature — it is the requirement.

Seeing it in practice

I ship this pipeline in ToolsMonk's Background Remover — drag an image in, the ~80 MB model is fetched and cached, inference runs locally, and a transparent PNG downloads. The tool reports "100% private: processed in your browser, never uploaded" because that is literally the execution model. The same suite is available as a Windows app and an Android app for offline use.

If you're implementing this yourself

• Start with ONNX Runtime Web and a U2-Netp ONNX export; measure before optimizing.

• Put inference in a Worker from day one, and get your COOP/COEP headers right before debugging anything else.

• Cache the model with the Cache API — first-load is a one-time cost, but make it explicit to the user.

• Test the mask on hair. It will tell you immediately whether your feathering radius is right.

The browser is now a perfectly good ML runtime for single-image workloads. The next time a feature "needs a backend", check whether an 80 MB model and a canvas can do it locally instead — the privacy story writes itself.

The stack that makes client-side PDF work possible

Three libraries carry most of the weight:

• pdf-lib — creating and modifying PDFs (merge, split, page rotation, form filling). Pure JS, works in every modern browser, no server needed.

• pdf.js (Mozilla) — rendering pages to canvas. This is your viewer and the base for any "edit what you see" UI.

• Tesseract.js — OCR via WebAssembly. Slower than server OCR for big scans, but for a 10-page document it's perfectly usable.

The merge operation is the simplest place to start:

import { PDFDocument } from 'pdf-lib';

async function mergePdfs(files) {
  const out = await PDFDocument.create();
  for (const file of files) {
    const src = await PDFDocument.load(await file.arrayBuffer());
    const pages = await out.copyPages(src, src.getPageIndices());
    pages.forEach(p => out.addPage(p));
  }
  return await out.save();
}

That's a real merge function — about 10 lines, zero uploads.

The problems that surprised me

1. Fonts are the hard part of "edit a PDF". Embedding a font into a PDF with pdf-lib requires a valid TTF. You cannot reference the user's system fonts, so you ship the fonts you offer. Each font is 50-400KB — the real engineering is which 6 fonts you pick.

2. Compression is really image resampling. "Compress PDF" almost always means: find the large images inside pages, downsample them, rewrite the document. With pdf.js you can rasterize pages to canvas at a chosen DPI and rebuild — crude, but effective for scan-heavy files.

3. OCR in a worker, or the tab dies. Tesseract.js will happily block the main thread for seconds. It must go into a Web Worker with a progress callback, or users assume the page froze.

4. Memory, not speed, is the ceiling. A 300-page PDF as an ArrayBuffer plus rendered canvases will eat gigabytes. Page virtualization (render only visible pages, evict the rest) is not optional.

5. Signatures need canvas, not DOM. Capture the drawn signature as a transparent PNG canvas, then embed it with pdf-lib's drawImage at the click coordinates. Coordinate mapping between the rendered canvas and PDF user space (origin bottom-left, remember) is where the bugs live.

Where this runs in production

I ship these techniques in ToolsMonk, a free suite of 250+ tools where the PDF operations (merge, split, compress, sign, OCR, convert) run client-side, available on the web, Windows and Android.

Takeaways

• Client-side PDF processing is production-viable in 2026; pdf-lib + pdf.js + a worker is the core.

• Budget your engineering for fonts, memory, and coordinate math — not the PDF spec.

• If you're building one, start with merge: it's satisfying, useful, and teaches you the arrayBuffer lifecycle you'll need everywhere else.

What have your experiences been with pdf-lib or pdf.js? I'd genuinely like to compare notes on the memory-management tricks.