DEV Community: Casey Marlin

What's actually inside an image's DPI tag (and why changing it is lossless)

Casey Marlin — Sun, 06 Sep 2026 02:56:22 +0000

A print shop rejected a 4000 × 2667 px photo last week because the file "was only 72 DPI". The photo had more than enough pixels for the 8 × 10 in print they were making — at 300 DPI that size only needs 2400 × 3000. Nothing about the image was wrong. One integer in the file header was.

This post is about where that integer lives, byte by byte, and why rewriting it doesn't touch a single pixel.

DPI is metadata, not resolution
"Resolution" gets used for two unrelated things:

Pixel dimensions — how many samples the image has. 4000 × 2667. This is the actual information content.
Density tag — a hint that says "when you put this on paper, space the pixels N to the inch". 72, 96, 300, whatever.
Screens ignore the density tag completely. Browsers map image pixels to CSS pixels and never read it. The tag only matters when something is about to lay ink on a physical surface — or when a form-validation script on an upload portal reads it and refuses your file.

Print size is always pixels ÷ DPI. A 3000 px wide image tagged 72 DPI "wants" to be 41.7 inches wide. The same file tagged 300 DPI "wants" to be 10 inches. Same pixels. Same sharpness at the same physical size. Different suggestion.

Where the tag lives: three formats, three places
JPEG — JFIF APP0 segment
Right after the SOI marker (FF D8), most JPEGs carry an APP0 segment with the JFIF header:

FF E0 APP0 marker
00 10 length (16)
4A 46 49 46 00 "JFIF\0"
01 02 version 1.02
01 density units: 0 = none, 1 = dots/inch, 2 = dots/cm
01 2C X density (0x012C = 300)
01 2C Y density
00 00 thumbnail w/h
That's it. Two big-endian uint16 values and a units byte. Rewriting "72 DPI" to "300 DPI" means changing 00 48 to 01 2C at a fixed offset and making sure the units byte is 01. The entropy-coded scan data that follows — the actual compressed pixels — is untouched.

JPEG — EXIF XResolution / YResolution
Cameras usually write an APP1 EXIF segment too, and it has its own resolution fields: tags 0x011A (XResolution) and 0x011B (YResolution) as RATIONAL values (two uint32s: numerator / denominator), plus 0x0128 ResolutionUnit (2 = inch, 3 = cm).

So a JPEG can carry the density twice, and they can disagree. Photoshop reads EXIF first. Windows Explorer reads... it depends on the version. A proper tool rewrites both so every reader agrees.

PNG — the pHYs chunk
PNG stores it in an optional pHYs chunk before IDAT:

00 00 00 09 length (9)
70 48 59 73 "pHYs"
00 00 2E 23 pixels per unit, X (0x2E23 = 11811)
00 00 2E 23 pixels per unit, Y
01 unit: 1 = metre
xx xx xx xx CRC32
Notice PNG doesn't store inches. It stores pixels per metre. 300 DPI = 300 / 0.0254 = 11811 px/m. That's why a PNG "set to 300 DPI" sometimes reads back as 299.99 — the metre value is an integer and 300 doesn't divide cleanly.

If the chunk is absent (most screenshots, most web-exported PNGs), there is no DPI. Any number a viewer shows you is that viewer's default, not a property of the file.

Why rewriting it is lossless
In all three cases the density fields are in a header segment or chunk that sits before and separate from the compressed image data. Changing them:

doesn't decode the pixels
doesn't re-encode the pixels
doesn't touch JPEG quantization tables or Huffman data
doesn't touch PNG IDAT chunks
The only thing you have to get right is the PNG CRC (recompute it over the chunk type + data) and, for JPEG, not shifting any offsets — the fields are fixed-width so an in-place overwrite is safe.

Contrast with what "Image → Resize → 300 DPI" does in most editors: it decodes, optionally resamples, and re-encodes. For JPEG that's a generation of quality loss you never needed to take.

Reading pHYs in ~15 lines of JavaScript
async function readPngDpi(file) {
const buf = new Uint8Array(await file.arrayBuffer());
const dv = new DataView(buf.buffer);
let off = 8; // skip PNG signature
while (off < buf.length) {
const len = dv.getUint32(off);
const type = String.fromCharCode(...buf.slice(off + 4, off + 8));
if (type === "pHYs") {
const ppuX = dv.getUint32(off + 8);
const unit = buf[off + 16];
return unit === 1 ? Math.round(ppuX * 0.0254) : null; // px/m → DPI
}
if (type === "IDAT") return null; // pHYs must precede IDAT
off += 12 + len; // length + type + data + CRC
}
return null;
}
Writing is the same walk plus a CRC32 and an ArrayBuffer splice. JFIF is even simpler — it's a fixed offset if the APP0 segment is where it usually is (and you should verify the JFIF\0 signature rather than assume).

The trap on the other side
Because the tag is so easy to change, "increase image DPI" tools are everywhere, and half of them quietly imply that raising the number makes a small image printable. It doesn't. An 800 × 600 px image tagged 300 DPI is a 2.67 × 2 in print. Tagging it 600 makes it a 1.33 × 1 in print. The pixels are the ceiling; the tag is just where you set the ruler.

The honest workflow: check pixel dimensions ÷ target DPI ≥ print size. If yes, rewrite the tag and stop. If no, you need more pixels — a larger original, a rescan, or an actual upscaler (which is a different, lossy operation).

I put this in a browser tool
I got tired of opening Photoshop to change one integer, so I built SetDPI — it does the JFIF / EXIF / pHYs rewrite described above entirely in the browser with a FileReader and a Blob. Nothing is uploaded; you can load the page and go offline. There's also a DPI checker that reads all three fields and tells you when they disagree or when the PNG simply has no pHYs chunk, instead of inventing 72.

If you're building anything that handles user-uploaded images, the takeaway is smaller than the tool: read the density fields, don't trust them, and never resample a file that only needed its label fixed.

CSV to vCard: the version minefield (and how to stop imports garbling names)

Casey Marlin — Thu, 20 Aug 2026 08:12:49 +0000

Every phone and both big contact clouds will happily export your
address book — and then be remarkably picky about what they re-import.
If you've ever moved contacts via a spreadsheet and ended up with garbled
names or missing phone labels, the culprit is almost always the same:
which vCard you generated.

What a vCard actually is

.vcf is plain text, one BEGIN:VCARD … END:VCARD block per person.
A well-behaved 3.0 card:

BEGIN:VCARD
VERSION:3.0
N:García;José;;;
FN:José García
TEL;TYPE=CELL:+34600000001
EMAIL;TYPE=INTERNET:jose@example.com
ORG:Acme GmbH
END:VCARD

Two name fields, and you need both:

N is structured — Family;Given;Middle;Prefix;Suffix. The semicolons are separators, so a semicolon inside a name must be escaped as \;.
FN is the display name, and it's required in 3.0/4.0. Omit it and some importers silently drop the card.

And the fact almost nobody uses: one .vcf can hold your entire address
book — just concatenate the blocks. No zips, no file-per-contact.

The version minefield

Version	Year	Non-ASCII handling	In 2026
2.1	1996	`QUOTED-PRINTABLE`	Everything imports it; nothing should still write it
3.0	1998	plain UTF-8	The safe target. Google Contacts exports it; iOS/iCloud, Android, Outlook all import it cleanly
4.0	2011	plain UTF-8	Nicest spec, patchiest importer support — still

If you've ever opened a .vcf and seen =E4=BD=A0=E5=A5=BD where a name
should be, that's vCard 2.1's quoted-printable encoding — the #1 source
of "my contacts imported as gibberish". The fix is boring: generate
3.0, in UTF-8, and move on. 4.0 gains you nothing for a contact dump
and costs you compatibility.

From CSV rows to cards

The annoying part isn't the serializer — it's that every ecosystem's CSV
headers differ. Google's export says Given Name / Family Name,
Outlook's says First Name / Last Name, and your hand-made sheet says
whatever it says. Any converter is really a column-mapping problem
with 25 lines of formatting bolted on:

const esc = s => String(s ?? "")
  .replace(/\\/g, "\\\\").replace(/;/g, "\\;")
  .replace(/,/g, "\\,").replace(/\r?\n/g, "\\n");

const card = r => [
  "BEGIN:VCARD",
  "VERSION:3.0",
  `N:${esc(r.last)};${esc(r.first)};;;`,
  `FN:${esc([r.first, r.last].filter(Boolean).join(" "))}`,
  r.cell  && `TEL;TYPE=CELL:${esc(r.cell)}`,
  r.work  && `TEL;TYPE=WORK:${esc(r.work)}`,
  r.email && `EMAIL;TYPE=INTERNET:${esc(r.email)}`,
  r.org   && `ORG:${esc(r.org)}`,
  "END:VCARD",
].filter(Boolean).join("\r\n");

const vcf = rows.map(card).join("\r\n") + "\r\n";

Wire rules are the same as iCalendar, because the formats share ancestry
(RFC 2425's directory profile): CRLF line endings, long lines folded
at 75 octets with a space starting each continuation line.

Phone numbers: keep E.164 (+34600000001) if you can. Importers don't
validate numbers, but sync engines dedupe far better when the format is
consistent.

Verify before you point it at your phone

My test loop: import the file into Google Contacts first — it
reports how many cards it read, and can undo. Then sync, AirDrop the
.vcf to an iPhone, or open it in Android's Contacts app. If Google reads
297 of 300 cards, the missing three almost always have an unescaped
semicolon or a blank FN.

For the mapping-table part I ended up building
a browser-based CSV ⇆ vCard converter with an
editable column-mapping step — it reads your headers, guesses the
mapping, and lets you correct the guess before writing 3.0 cards. Free
and client-side; nothing uploads.

But honestly, for a one-off with clean columns, the 25 lines above will
do. The format survived 30 years by being boring — write the boring
version of it.

Bulk-adding events to a calendar app: the .ics format from scratch

Casey Marlin — Sun, 16 Aug 2026 21:41:41 +0000

Last month I had a spreadsheet with ~40 shifts — date, start, end, who's
on call — and needed them in Google Calendar. The obvious route is
Google's CSV import. It exists, and it half-works: dates get parsed
US-style (03/04 is March 4th whether you meant that or not), there's no
timezone column, all-day events hinge on a magic All Day Event column,
and malformed rows are dropped without a word. Apple Calendar won't take
CSV at all.

The format every calendar app does agree on is iCalendar — the
.ics file, RFC 5545. And it's just text, so you can generate it
yourself.

A minimal .ics file

BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//demo//csv-export//EN
BEGIN:VEVENT
UID:20260901-0900-standup@example.com
DTSTAMP:20260812T120000Z
DTSTART;TZID=Europe/Berlin:20260901T090000
DTEND;TZID=Europe/Berlin:20260901T100000
SUMMARY:Team standup
END:VEVENT
END:VCALENDAR

One VEVENT block per spreadsheet row. Three properties are mandatory:
UID, DTSTAMP, DTSTART. A useful side effect of UID: calendar apps
dedupe on it, so re-importing a corrected file doesn't create 40
duplicates. Derive it from the row data — don't randomize it.

Dates are where imports go to die

.ics has three flavors of timestamp, and mixing them up is the #1
source of "my events are six hours off":

DTSTART:20260901T090000Z — trailing Z means UTC.
DTSTART;TZID=Europe/Berlin:20260901T090000 — wall-clock time in a named IANA timezone. Usually what you want.
DTSTART:20260901T090000 — no Z, no TZID: "floating" time, rendered in whatever timezone the viewer's calendar uses.

All-day events are their own trap:

DTSTART;VALUE=DATE:20260901
DTEND;VALUE=DATE:20260902

DTEND is exclusive — a one-day event ends on the next date.
Skip the +1 and multi-day events render one day short.

The two rules nobody reads the spec for

1. Line endings are CRLF. Most parsers forgive plain \n; Outlook
historically hasn't. Join with \r\n and stop worrying.

2. Lines fold at 75 octets. Long DESCRIPTION values get split, and
each continuation line starts with a single space:

DESCRIPTION:Quarterly review with the plat
 form team — bring the Q3 numbers

It's 75 octets, not characters — emoji and CJK text hit the limit
sooner because UTF-8 is multibyte. And inside TEXT values, , ; \
must be backslash-escaped; literal newlines become \n.

Wiring it up in JavaScript

const esc = s => String(s ?? "")
  .replace(/\\/g, "\\\\").replace(/([,;])/g, "\\$1")
  .replace(/\r?\n/g, "\\n");

const fold = line => {
  if (new TextEncoder().encode(line).length <= 75) return line;
  const out = []; let buf = "";
  for (const ch of line) {
    if (new TextEncoder().encode(buf + ch).length > (out.length ? 74 : 75)) {
      out.push(buf); buf = ch;
    } else buf += ch;
  }
  out.push(buf);
  return out.join("\r\n ");
};

const event = row => [
  "BEGIN:VEVENT",
  `UID:${row.date}-${row.start}@yourdomain.example`,
  `DTSTAMP:${new Date().toISOString().replace(/[-:]|\.\d{3}/g, "")}`,
  `DTSTART;TZID=${row.tz}:${row.date}T${row.start}00`,
  `DTEND;TZID=${row.tz}:${row.date}T${row.end}00`,
  `SUMMARY:${esc(row.title)}`,
].map(fold).join("\r\n") + "\r\nEND:VEVENT";

const ics = ["BEGIN:VCALENDAR", "VERSION:2.0",
  "PRODID:-//you//csv-to-ics//EN",
  ...rows.map(event), "END:VCALENDAR"].join("\r\n") + "\r\n";

Serve it as text/calendar, or hand it to
URL.createObjectURL(new Blob([ics])) for a download link. Recurring
events are one property away (RRULE:FREQ=WEEKLY;BYDAY=MO,WE) — a
rabbit hole worth its own post.

I eventually packaged all of this — column mapping, timezone selection,
folding, escaping, the all-day off-by-one — into
csvtoics.app, a free browser-based converter
(File API end to end, nothing uploads). As of this week it also reads
.xlsx directly — SheetJS in the browser — so the Save-As-CSV step, and
the locale date-mangling that comes with it, is gone entirely. Useful if
you have a spreadsheet right now and no appetite for the spec.

Either way: after generating, import into Google Calendar and open the
file in Apple Calendar or Outlook once. The strict parsers are the ones
that find your bugs.

What's actually inside an .eml file (and how to read one without Outlook)

Casey Marlin — Sun, 16 Aug 2026 09:03:55 +0000

Someone forwards you an email as a .eml attachment. You double-click it,
and… nothing useful happens. On Windows it tries to launch Outlook; on a
work laptop with no mail client you get a wall of raw text. So what is
this file, and how do you read it programmatically?

An .eml file is just text

Despite the scary-looking contents, a .eml file is a plain-text file in
MIME format (RFC 5322 + RFC 2045). Open one in a text editor and the
top looks like this:

From: Alice <alice@example.com>
To: Bob <bob@example.com>
Subject: Q3 numbers
Date: Tue, 12 Aug 2026 09:14:00 +0000
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="_boundary_42"

--_boundary_42
Content-Type: text/html; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

<p>Here are the numbers you asked for.</p>

--_boundary_42
Content-Type: application/pdf; name="report.pdf"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="report.pdf"

JVBERi0xLjQKJc... (base64 continues)
--_boundary_42--

Three things to notice:

Headers come first, one per line, until the first blank line.
Content-Type: multipart/...; boundary="..." means the body is split into parts, separated by --<boundary>.
Each part has its own headers and its own encoding — usually quoted-printable for text and base64 for attachments.

Reading it in JavaScript

The nice thing about MIME being plain text is that you can parse it in the
browser with the File API — no server, no upload. The skeleton:

async function readEml(file) {
  const raw = await file.text();

  // 1. Split headers from body at the first blank line
  const sep = raw.indexOf("\r\n\r\n") !== -1 ? "\r\n\r\n" : "\n\n";
  const [rawHeaders, body] = splitOnce(raw, sep);

  // 2. Parse headers into a map (careful: values can wrap onto
  //    continuation lines that start with whitespace)
  const headers = parseHeaders(rawHeaders);

  // 3. If multipart, split the body on the boundary and recurse
  const ctype = headers["content-type"] || "";
  const boundary = /boundary="?([^";]+)"?/i.exec(ctype)?.[1];
  const parts = boundary
    ? body.split(`--${boundary}`).slice(1, -1).map(parseMimePart)
    : [{ headers, body }];

  return { headers, parts };
}

The two places people get bitten:

Header folding. A long Subject: can wrap onto the next line if that line starts with a space or tab. Un-fold before you parse, or you'll truncate subjects.
Encoded words. Non-ASCII headers look like =?UTF-8?B?SsOpc3Vz?= (RFC 2047). Decode them or "José" turns into line noise.

Attachments are just the base64 part decoded into a Blob, which you can
hand straight to a download link:

const bytes = Uint8Array.from(atob(part.body.replace(/\s/g, "")),
                              c => c.charCodeAt(0));
const url = URL.createObjectURL(new Blob([bytes], { type: mimeType }));

The gotchas that make it a real project

A toy parser handles the happy path. A robust one has to deal with:

.emlx (Apple Mail) — an .eml wrapped with a length prefix and a plist footer you have to strip.
.msg (Outlook) — not MIME at all; it's an OLE compound binary file that needs a completely different parser.
Inline images referenced by cid: in the HTML body, which live as separate MIME parts.
Rendering untrusted HTML safely (sandboxed iframe, scripts stripped) so a phishing sample can't run anything.

I got tired of re-solving this, so I built a free browser-based viewer that
handles all of the above —
emltool.com — everything is parsed locally with the
File API, nothing is uploaded. Source of truth if you just need to open
an .eml/.emlx/.msg file without installing anything.

Hope the format breakdown saves someone an afternoon of squinting at
base64. If you're implementing your own parser, the RFC 2047 encoded-word
decoding is the part worth testing hardest.