DEV Community: Nina Hart

What 300 DPI actually means (and why your passport photo still gets rejected)

Nina Hart — Thu, 22 Oct 2026 02:28:36 +0000

A passport photo rejection is one of the more frustrating pieces of paperwork in modern life. You take a photo, an online form tells you it needs to be 300 DPI, you run it through something that says "300 DPI", you upload it, and it comes back rejected for the same reason.

The reason is almost always that the form is not checking DPI at all. It is checking pixel dimensions. And the tool you used changed the number in a header without changing the number of pixels, because those are two entirely different things.

DPI is a division problem, not a stored quantity of detail

"300 DPI" means: if you print this at 300 dots per inch, it will be one inch wide.

That number is only meaningful when you also know the print size. Which means DPI can never be a property of a file on its own — it is always a statement about a file plus a physical size.

If you want a 2 × 2 inch photo at 300 DPI, you need:

2 in × 300 dpi = 600 pixels
2 in × 300 dpi = 600 pixels

600 × 600. That is the entire requirement. Nothing else matters.

Here are the numbers for the sizes that come up most often:

Target size	Pixels at 300 DPI
2 × 2 in (US passport)	600 × 600
35 × 45 mm (Schengen visa)	413 × 531
4 × 6 in print	1200 × 1800
8 × 10 in print	2400 × 3000
A4 at print quality	2480 × 3508

Note that the 35 × 45 mm case is not a round number. 35 mm is 1.378 inches; times 300 is 413.4. Every passport photo tool that gives you "413 × 531" is rounding down the same two divisions.

What the file actually stores

A JPEG has nowhere to put "this looks good at 300 DPI" in any absolute sense. What it stores is a hint for the printing software, and it lives in the JFIF header:

units — 0 means "no units, aspect ratio only", 1 means dots per inch, 2 means dots per centimetre
X density / Y density — the number, per unit

That is three fields, five bytes total, sitting near the start of the file. It is metadata in the purest sense: changing it does not touch a single pixel.

Which is exactly why the trick of "resave it at 300 DPI" produces a file that still gets rejected. If your photo is 800 pixels wide and you rewrite the header to say 300 DPI, you now have a file that claims to be 2.67 inches wide at print resolution. It is still 800 pixels. If the form wanted 600 × 600, you were already fine. If it wanted 1200 × 1800, you are still short and no header edit will help.

Reading it out of a JPEG

Most tools will not show you the raw value, so here is how to check it yourself. The JFIF APP0 segment starts with FF E0, and after the two length bytes comes the ASCII string JFIF\0:

async function readJpegDensity(file) {
  const bytes = new Uint8Array(await file.arrayBuffer());
  const view = new DataView(bytes.buffer);

  if (view.getUint16(0) !== 0xffd8) return null; // not a JPEG

  let off = 2;
  while (off < bytes.length - 16) {
    if (bytes[off] !== 0xff) return null;

    const marker = bytes[off + 1];
    const length = view.getUint16(off + 2);

    // APP0 + "JFIF"
    if (marker === 0xe0 && view.getUint32(off + 4) === 0x4a464946) {
      const units = bytes[off + 11]; // 0 aspect, 1 dpi, 2 dpcm
      const x = view.getUint16(off + 12);
      const y = view.getUint16(off + 14);
      return { units, x, y };
    }

    if (marker === 0xda) break; // start of scan: no JFIF segment
    off += 2 + length;
  }

  return null;
}

If this returns null, or returns units: 0, the file has no DPI to speak of. Whatever software you opened it in invented a default — 72 and 96 are the usual guesses, and neither is stored anywhere.

The trap: canvas will not write it for you

This is the part that catches people building the tool rather than using it. Draw an image to a canvas, export it:

const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.92 });

The browser produces a valid JPEG. It does not produce one with a meaningful density value. Canvas has no API for setting DPI, and toBlob takes a type and a quality, nothing else. So any claim that a canvas-based tool outputs "300 DPI" is either wrong or doing something below the encoding layer.

I ran the reader above against two files while writing this — one a marketplace test fixture, one straight out of a browser canvas. Both came back identical:

{ units: 0, x: 1, y: 1 }

Not 72, not 96. A declared density of one dot per inch with no unit attached, which is the encoder saying "I have no opinion." Every piece of software that opens these files then invents its own default, and they do not agree with each other.

Doing it below the encoding layer is not hard, because you are editing five bytes:

async function setJpegDensity(blob, dpi) {
  const bytes = new Uint8Array(await blob.arrayBuffer());
  const view = new DataView(bytes.buffer);

  let off = 2;
  while (off < bytes.length - 16) {
    if (bytes[off] !== 0xff) break;

    const marker = bytes[off + 1];
    const length = view.getUint16(off + 2);

    if (marker === 0xe0 && view.getUint32(off + 4) === 0x4a464946) {
      bytes[off + 11] = 1;          // units = dots per inch
      view.setUint16(off + 12, dpi);
      view.setUint16(off + 14, dpi);
      return new Blob([bytes], { type: 'image/jpeg' });
    }

    if (marker === 0xda) break;
    off += 2 + length;
  }

  return blob; // no JFIF segment to patch
}

Two caveats worth knowing before you ship this. First, a PNG stores its resolution differently (a pHYs chunk, in pixels per metre), so this code is JPEG-only. Second, if the encoder omitted the JFIF segment entirely, there is nothing to patch in place and you would have to insert one — at which point you are writing a JPEG muxer and should reconsider the scope of your afternoon.

So what should you actually do

Work backwards from the print size:

Decide the physical size the form wants.
Multiply by the DPI it demands to get pixels.
Resize to that pixel count. Crop to the required aspect ratio first, or you will end up stretching a face.
If a downstream system insists on a DPI value in the header, write it after resizing, not instead of resizing.

Step 4 is optional. Step 3 is the one that gets your photo accepted.

And if the form still rejects it, the problem is almost never DPI. It is background colour, head size as a percentage of frame, glasses, shadow, or a file size ceiling measured in kilobytes. Those are all checkable in the tab, before you upload anything to anyone.

This is the reasoning behind ToolCaravan's ID photo tool — crop to a passport or visa spec, get the exact pixel dimensions, all in the browser. No upload, no account, no watermark.

Client-side image compression: what actually gets smaller

Nina Hart — Wed, 21 Oct 2026 13:29:39 +0000

"Compress this image" is four different requests wearing the same coat:

Make it fit an upload limit.
Make it load faster.
Make it look less like it was shot on a phone from 2009.
Make it stop being 12 MB.

Those need different answers, and most "compressor" tools apply all of them at once, then hand you back something that looks like it went through a washing machine.

Here's what each lever actually does, in a browser, with no server involved.

Lever one: dimensions (the big one)

Pixels cost more than bytes-per-pixel. Halve the width and height and you have a quarter of the pixels — and roughly a quarter of the file size, at identical quality settings.

For listing images this is usually not a trade-off at all. A marketplace that asks for 2000 × 2000 does not care that you uploaded 4000 × 4000, and neither does anyone browsing on a phone. Downscaling to the size that will actually be displayed is free quality.

The catch is that resizing has to be done well. drawImage() at a large reduction ratio skips pixels and produces aliasing; doing it in two steps, or letting the browser use a better filter, preserves edges.

async function downscale(blob, maxEdge) {
  const bmp = await createImageBitmap(blob, { imageOrientation: 'from-image' });
  const scale = Math.min(1, maxEdge / Math.max(bmp.width, bmp.height));

  const w = Math.round(bmp.width * scale);
  const h = Math.round(bmp.height * scale);

  const canvas = new OffscreenCanvas(w, h);
  const ctx = canvas.getContext('2d');
  ctx.imageSmoothingQuality = 'high';
  ctx.drawImage(bmp, 0, 0, w, h);

  return canvas.convertToBlob({ type: 'image/jpeg', quality: 0.9 });
}

If the scale factor is smaller than about 0.5, do it in passes — halve, then halve again — rather than asking the browser to throw away three quarters of the pixels in one call.

Lever two: re-encoding quality

Every time you save a JPEG, the encoder quantises the DCT coefficients and throws information away. Lower quality means coarser quantisation: smaller file, more visible blocking in flat areas and more ringing around edges.

For photos that will be viewed at normal size, 0.85–0.92 is usually indistinguishable from the original. Below 0.7, gradients start to band and text in the image falls apart.

The important part: this is lossy on top of lossy. If the input is already a JPEG, re-encoding is a second generation of damage. Which is why you should keep the untouched original and only ever re-encode from it — never from a file you already compressed.

Canvas gives you the encoder directly:

const out = await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.85 });

Lever three: the format

Same pixels, different encoder:

// Chrome, Edge, Firefox: usually 25–35% smaller than JPEG at equal quality.
const webp = await canvas.convertToBlob({ type: 'image/webp', quality: 0.85 });

WebP is the pragmatic default for the web in 2026 and support is effectively universal. AVIF compresses better still, but canvas can't encode it — you'd need a WASM encoder, and the CPU cost stops being worth it for a single photo.

Note that format choice and compatibility pull in opposite directions. If the destination is a marketplace upload form that only accepts JPEG or PNG, WebP is not an option no matter how small it is. That's a common reason these tools keep a format switch rather than always choosing for you.

Hitting a target file size

"Under 100 KB" is a constraint, not a quality setting. The straightforward approach is a binary search over quality, re-encoding until you're under the limit:

async function encodeUnder(canvas, targetBytes) {
  let lo = 0.3, hi = 0.95, best = null;

  for (let i = 0; i < 7; i++) {
    const q = (lo + hi) / 2;
    const blob = await canvas.convertToBlob({ type: 'image/jpeg', quality: q });

    if (blob.size <= targetBytes) {
      best = blob;
      lo = q;          // try to keep more quality
    } else {
      hi = q;          // too big, encode harder
    }
  }
  return best ?? await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.3 });
}

Seven iterations resolves quality to about 0.005, which is finer than anyone can see. But note what this does not do: if the image is 4000 × 4000, no quality setting will get it under 100 KB without turning it to mush. The search should run after downscaling, not instead of it.

A good order of operations:

Downscale to the size you actually need.
If still too big, search over quality.
If still too big, the target is unrealistic for this image — tell the user instead of silently destroying it.

That last step is the one most tools skip, and it's why you sometimes get back a 100 KB file that looks like a watercolour.

What you lose, and what you gain

Lost: a generation of quality, and all the metadata. Canvas re-encoding strips EXIF, which takes the GPS coordinates with it. For a product photo that's a feature. For an archive, it's data loss.

Gained: orientation baked in correctly, colour profile normalised, and a file that fits where you're uploading it.

Real numbers from a run I did while building this: a 1440 × 960 JPEG at 194 KB, resized to 2000 × 2000 with padding, came out at 286 KB — bigger, because the frame got larger, but correctly sized for the marketplace. Compressing the same file down instead, at reduced quality, got it under 100 KB with no visible change at screen size.

Why do it in the tab

The alternative is uploading a photo to a stranger's server so it can do arithmetic your laptop is already capable of. For one image that's a mild inconvenience. For a seller working through a folder of unreleased products, it's a data-handling decision made by accident.

Canvas, createImageBitmap, and convertToBlob are all you need, and they're already there.

This is the approach behind ToolCaravan — small browser tools for product photos that run entirely on your device. No account, no upload, no watermark.

How a HEIC file becomes a JPG inside your browser

Nina Hart — Wed, 21 Oct 2026 13:14:50 +0000

Someone sends you a photo from an iPhone. You drop it into a web form. The form says "unsupported file type" and that's the end of the conversation.

The file is a .heic. It is a perfectly normal photo. Your browser just can't read it.

This post is about why, and about what actually happens when you fix it client-side.

What HEIC actually is

HEIC is not an image format in the way JPEG is. It's a container — HEIF — holding an image encoded with HEVC (H.265), the same codec used for 4K video.

Apple switched the iPhone camera default to it in 2017 with iOS 11. The reasons were boring and good: half the file size of JPEG at the same visual quality, plus support for depth maps, HDR, and image sequences in the same container.

The problem is the second half of that sentence. HEVC is patent-encumbered. Shipping a decoder means paying for a licence, so most browser engines simply don't. Safari decodes HEIC because it sits on top of the operating system's own codecs. Chrome, Firefox, and Edge on Windows generally will not, and <img src="photo.heic"> just fails.

So the file is fine. The browser is the one that's missing a part.

Three ways out

There are basically three options when you control the site:

Ask the user to convert it themselves. Bad. They have a photo, not a workflow.
Upload it and convert on a server. Works, but now someone's unreleased product photo is sitting on your disk, and you're paying for CPU to decode video frames.
Ship a decoder to the browser and do it locally. Costs bandwidth, saves everything else.

Option 3 is the interesting one, and it's more practical than it sounds.

Shipping the decoder, but only when it's needed

The decoder is a compiled build of libheif wrapped in JavaScript. A minified build lands around 1.3 MB — bigger than your average JS bundle, smaller than a single photo from a modern phone.

The obvious mistake is putting that in your main bundle, where every visitor pays for it whether they have a HEIC or not. Instead, load it on demand, after you've confirmed the file really is HEIC.

That means sniffing the file itself rather than trusting the extension or the MIME type. Both lie: a .heic can be a renamed JPEG, and browsers report image/heic inconsistently.

A HEIF file starts with a box header, and the brand is ASCII at a fixed offset:

async function looksLikeHeic(file) {
  const buf = new Uint8Array(await file.slice(0, 32).arrayBuffer());
  const ascii = (from, to) =>
    String.fromCharCode(...buf.slice(from, to));

  // ISO base media file: bytes 4..8 are 'ftyp'
  if (ascii(4, 8) !== 'ftyp') return false;

  // Brand lives at 8..12; compatible brands follow.
  const brand = ascii(8, 12);
  const heifBrands = ['heic', 'heix', 'hevc', 'hevx', 'mif1', 'msf1'];
  return heifBrands.includes(brand) ||
         heifBrands.some(b => ascii(16, 32).includes(b));
}

Thirty-two bytes, no dependency, and you can decide whether to fetch 1.3 MB before you fetch it.

let decoderPromise = null;

function loadDecoder() {
  // The build is a single file that attaches a global.
  decoderPromise ??= new Promise((resolve, reject) => {
    const s = document.createElement('script');
    s.src = '/vendor/heic2any.min.js';
    s.onload = () => resolve(window.heic2any);
    s.onerror = reject;
    document.head.appendChild(s);
  });
  return decoderPromise;
}

Cache the promise, not the result — two photos dropped at once should share one download, not start two.

Decoding, and the part people get wrong

The actual conversion is a one-liner:

const heic2any = await loadDecoder();

const jpgBlob = await heic2any({
  blob: file,
  toType: 'image/jpeg',
  quality: 0.92,
});

What matters is what's around it.

Do one file at a time. Decoding is CPU-bound and the decoded frame is uncompressed — a 12-megapixel photo is roughly 48 MB in memory as RGBA. Decode ten in parallel and you'll meet the tab's memory limit on a laptop that was fine a second ago.

Keep the quality high. 0.92 is a good default: it stays visually clean at 100% zoom and still produces something a marketplace form will accept. Going lower to save bytes is better handled by resizing, which I'll come back to.

Respect orientation. Phone photos carry an EXIF orientation flag. If you decode and re-encode without honouring it, a portrait photo comes out sideways. Modern paths handle this if you ask them to — for canvas work, createImageBitmap(blob, { imageOrientation: 'from-image' }) does the right thing.

Let Safari skip the decoder. Safari can already open a HEIC. If the browser can, createImageBitmap() on the original file succeeds and you never download anything. Try the native path first; fall back to the JS decoder only when it throws.

async function toJpeg(file) {
  // Native path: Safari, and any browser that gained HEIC support.
  try {
    const bmp = await createImageBitmap(file, { imageOrientation: 'from-image' });
    const canvas = new OffscreenCanvas(bmp.width, bmp.height);
    canvas.getContext('2d').drawImage(bmp, 0, 0);
    return await canvas.convertToBlob({ type: 'image/jpeg', quality: 0.92 });
  } catch {
    // Everything else: pay the 1.3 MB.
    const heic2any = await loadDecoder();
    return await heic2any({ blob: file, toType: 'image/jpeg', quality: 0.92 });
  }
}

What it actually costs

On a normal laptop, a 1440 × 960 HEIC decodes and re-encodes in a few seconds. The first photo in a session also pays the decoder download; after that it's cached and the tab even works offline.

The output is usually larger than the input, and that's expected — you're trading compression efficiency for compatibility. A 40 KB HEIC becoming a 194 KB JPG is a normal result. If size matters, resize afterwards; that's a separate lever.

Why local matters here

This is the part that made me build it.

HEIC is the iPhone default, which means the photos people convert are personal: family pictures, and for anyone selling online, product shots of things that haven't launched yet. Uploading those to a converter you found in a search result is a small decision with a long tail — you have no idea what happens to the file, how long it's kept, or who can read it.

Doing it in the tab removes the question. The file is read by FileReader, decoded by a library that's already in the page, and written back as a Blob. If you open DevTools and watch the network panel while converting, you'll see the decoder load and nothing else. The photo never moves.

That's the whole trick: the browser was missing a codec, so we shipped it one — once, lazily, and then threw it away when the tab closes.

I built this into ToolCaravan, a set of small free browser tools for product photos. No account, no upload, no watermark — because the files are the point.