DEV Community: Ren

A 5.5 KB DXF file can expand to 100 million lines: budgeting a browser CAD viewer

Ren — Thu, 29 Oct 2026 13:03:19 +0000

I run a DXF viewer that works entirely in the browser. DXF is the text format CAD programs use to exchange drawings. The parser (from dxf-viewer; MIT and MPL 2.0) runs in a Web Worker, the drawing is built there and handed to the page, and the page draws it on a canvas. The file never goes to a server.

The files people open are drawings someone else sent them. A DXF file (the text kind) is just text, so anyone can write any drawing by hand. I wanted a crafted drawing to be unable to freeze or crash the tab. The part that took far longer than I expected was deciding what to count when setting a limit. This post is about that.

Small files, big drawings

DXF lets you define a group of entities as a block and place it any number of times with INSERT. An INSERT inside a block nests. A MINSERT places a block as a whole grid in one go.

Make a block B0 of 10 lines, a block B1 that inserts B0 ten times, B2 that inserts B1 ten times, and so on to B7, then insert B7 once. The file is 5.5 KB. Expanded naively, it is 10^8 lines: one hundred million.

A few of the samples from my tests (all written from scratch by a script):

Sample	File	Built naively
Blocks of 10 lines nested 7 deep, 10 inserts each	5.5 KB	100 million lines
A 20,000-character MTEXT in a 100 × 100 array	21 KB	200 million characters
An MTEXT line of 1,000 colour-changing runs, 14 × 14	7.5 KB	196,000 `<text>` in the print SVG
1,000 long lines, 40 × 40	78 KB	1.6 million lines across the screen
A self-intersecting 5,000-vertex star fill, 30 × 30	115 KB	900 fills taking about 0.9 s each at full screen

First attempt: count what is accepted

The builder (in the Worker) had a work budget from the start. It counts the coordinates, fills and text that enter the drawing; when the budget runs out it stops, and the page says "Too many objects: stopped after drawing about N lines, texts and other pieces."

At first it counted what was accepted into the drawing: the points of lines that would be drawn, the characters of text. A natural design. But every review round found one more path that did work without paying for it, five rounds in a row. Here are the paths, with a sample that hits each:

Expanding the nesting itself. Nest blocks that contain nothing drawable (only entity types the viewer does not draw) 9 deep. Nothing is accepted, so the budget never moves, while the expansion runs a billion times.
Hatch boundaries. The boundary points of a fill were an intermediate array, not counted as accepted geometry.
Markup that ends up empty. An MTEXT with 60,000 runs that parse to nothing (an underline code, %%u, wrapped in braces). No characters are accepted, but parsing them costs time and memory.
Refused copies. Insert a block as a 1,000 × 1,000 grid at a scale that puts every copy beyond 1e15. Each copy was made, then refused, and the making was never counted.
Unreadable coordinates and the cache. A polyline of 20,000 bulges starting at x = 1e999 (which parses to Infinity), inside a block. The cache that builds a block's points once and reuses them was building points even for coordinates that could not be used.

The five were in different places but had the same shape: the moment work was done and the moment it was paid for were different. With "pay on acceptance" or "ask first without paying", a copy made and then refused, an intermediate array, or a cache will always find a way to do work for free.

So there is now one place that pays, and it pays at the moment of allocation:

/**
 * The only charge: n units for what is about to be allocated, charged now,
 * whatever becomes of it (refused or discarded later, it is not refunded).
 * Past the budget it refuses, and from then on everything stops.
 */
alloc(n: number): boolean {
  if (this.stop) return false;
  if (!(this.work + n <= this.limits.maxWork)) {
    this.stop = true;
    return false;
  }
  this.work += n;
  return true;
}

Producers whose point count depends on the input (bulges, splines, hatch edges and patterns) count the points first, alloc() them, then make them. A block's entities are built once (and paid for then); each INSERT's copy is paid for before it is written. If a copy turns out unusable after it was written, it is dropped and the charge stays.

Entities whose coordinates cannot be read (1e999, NaN, beyond 1e15, scale 0, absurd angles) are skipped at the entrance without making anything, and counted as "unreadable coordinates".

Weights follow what is stored: a coordinate pair is one unit; a text is 32 units plus its runs, lines and characters. Looking at an entity or expanding a block is also one unit (that one is for time, not memory, and it closes the first path). The budget is 8 million units. The 100-million-line sample now stops after 2.48 million lines (1.6 s from reading to building, in Node), draws what it has, and says it stopped.

The page side: limits on a proxy get routed around

With the builder bounded, I set limits on the page: at most 4,096 draw batches (layer × colour × linetype), a print SVG of at most 64 MB and 200,000 elements, a layer menu of at most 300 rows. Review routed around these too.

1,000 long lines, 40 × 40 (78 KB). 1.6 million lines fit in the budget, in a single batch. Handed to one canvas stroke(), they freeze the page. As an experiment, stroking all 1.6 million in one stroke() on a 1,200 × 800 canvas in Chromium took 6.3 s at a width just under one pixel (0.999); at 1.25 device pixels (the normal width on a 2× screen) it had not finished after 170 s.

An MTEXT line of 1,000 colour runs, 14 × 14 (7.5 KB). The print SVG is 26 MB with 196,000 <text>, under both 64 MB and 200,000 elements. Just displaying that SVG in Chromium took the renderer from 81 MB to 1.9 GB.

Both limits counted the wrong thing. I wanted to bound time, and counted segments. I wanted to bound memory, and counted elements and characters.

Bound time with time. The drawing is cut into chunks with fixed upper limits (1,024 segments of lines, 256 arcs, and so on). A draw strokes chunk after chunk until about 20 ms have passed, then continues on the next animation frame. A zoom, pan or layer toggle drops the draw in progress and starts over. Stroking the same 1.6 million lines 1,024 at a time took at most 24 ms per chunk even at 1.25 px (27.5 s in all).

The viewer adds two more things. In a batch of very many long lines, lines that coincide to a pixel on screen are drawn once (with this drawing fitted to a 1,200 × 800 view, 960,000 of the 1.6 million). And a heavy drawing (more than 20,000 segments and arcs on the shown layers) is drawn no wider than one pixel, even on a 2× screen. Opened in the viewer, this drawing takes 4–10 s to finish and 16–30 s to redraw after a zoom, with main-thread stalls of at most about 0.2 s (0.14–0.21 s over several runs), and the page stays usable.

Bound memory with memory. The print SVG is built while estimating the renderer's memory, with weights per element kind measured in Chromium:

// Measured from the renderer's memory when printing an A3 sheet to PDF (above an empty sheet)
export const PRINT_COST = { element: 1500, text: 9600, char: 150, position: 1300, byte: 13 };
export const MAX_PRINT_BYTES = 400 * 1024 * 1024;

Past 400 MB of estimate it stops and says the drawing is too large to convert for printing. The largest print SVG among the real drawings I have is 13 MB.

Slicing by time still leaks if a step is sized by count

Time slicing was not the end. Fill chunks were cut at "at most 1,024 loops".

Filling one self-intersecting star of 5,000 vertices (every edge spans the whole shape) across a 1,200 × 800 canvas takes 0.85 s in Chromium with the nonzero rule, which the viewer uses for a single loop (2.1 s with even-odd). A 20,000-vertex star takes 11.7 s with even-odd. Meanwhile 2,000 small circles fill in 4 ms. The number of loops says almost nothing about the cost. The 900 stars of the 30 × 30 grid fit in one step, and in review that step froze the page for over 300 s.

My working model is that the cost is decided by how many edges cross each row of the screen. Assuming each row's crossings have to be sorted, n crossings cost about n log n. I count that as scan work, and checked the model against measurements (with even-odd, the 5,000-vertex star is about 30 million units and 2.1 s, the 20,000-vertex star about 140 million units and 11.7 s: 72 ns and 83 ns per unit, close enough):

// Scan work of filling (or clipping by) loops: for each screen row crossed by n edges,
// n·log₂n, plus one per edge. k is the view scale; ty and H place the rows on screen.
function scanUnits(c: ArrayLike<number>, loops: [number, number][], k: number, ty: number, H: number): number {
  const rows = new Int32Array(H + 2); // edges crossing each row, as a difference array
  let edges = 0;
  const rowOf = (v: number) => Math.min(Math.max(ty - c[v * 2 + 1] * k, 0), H);
  for (const [s, e] of loops) {
    for (let v = s; v < e; v++) {
      let y0 = rowOf(v), y1 = rowOf(v + 1 < e ? v + 1 : s);
      if (y0 > y1) [y0, y1] = [y1, y0];
      rows[Math.ceil(y0)]++;
      rows[Math.ceil(y1)]--;
      edges++;
    }
  }
  let n = 0, units = edges;
  for (let r = 0; r <= H; r++) {
    n += rows[r];
    if (n > 0) units += n * Math.log2(Math.max(2, n));
  }
  return units;
}

(The real one skips the array when few rows are crossed, among other details.)

Measured in Chromium across fill and clip, both fill rules, at 1× and 2×, one unit took 5–138 ns. Going by the slowest, a step is 200,000 units (about 30 ms), and any single fill over 2 million units (about 0.3 s) is drawn as its outline instead, with a note under the drawing: "Filled shapes drawn as their outline only, too heavy to fill: N". Among the 34 real drawings I have, none were outlined.

Slicing by time still leaves the same hole if the size of a step is a count. The cap on a step should be an estimate of the operation's real work, calibrated by measurement.

A measuring trap: the canvas draws later

At first, the time slicing measured the wrong thing:

const t0 = performance.now();
while (performance.now() - t0 < 20) drawNextChunk(); // "drew for 20 ms"

Canvas calls are recorded when you make them and rasterised later, all at once. Stroking long lines 1,024 at a time, 429 chunks (440,000 lines) were "drawn" within 20 ms, and reading back a single pixel afterwards took 1.7 s. Recording raced ahead; the rasterising arrived at the end of the frame.

So after each step, the renderer reads one pixel, which makes that step's drawing actually happen, and only then checks the clock:

while (performance.now() - t0 < SLICE_MS) {
  const r = pass.next();             // draw one step
  this.ctx.getImageData(0, 0, 1, 1); // make it happen now; time is measured up to here
  if (r.done) { /* finished */ return; }
}
requestAnimationFrame(() => this.slice(pass));

Tests: run anything that might hang in its own process

If the bounding breaks, a crafted sample hangs the test run itself. So each build runs in a process of its own, and the test checks things like the time (8 s), the peak memory (1 GB), the size handed to the page (200 MB) and that it stayed within budget. There are 44 such samples now.

One more trap here: The child was started with spawnSync('npx', ['tsx', ...], { timeout }), and a timeout killed only npx. The tsx and node under it lost their parent and kept burning CPU for hours. Now node is started directly (process.execPath with --import tsx), and a timeout is SIGKILL.

The browser test sets a 20 ms setInterval on the page and records the longest gap between ticks while opening, zooming and toggling a layer; over 600 ms fails. Measured again for this post, on the long lines, the heavy-print MTEXT, the 900 stars and 1.6 million distinct large circles: the longest stall was 116–214 ms at both 1× and 2×.

Limits that remain

Not freezing is not the same as being fast. In the 900-star drawing, all 900 are drawn as outlines, and it still takes 57 s to redraw after a zoom on a 2× screen (the page stays usable).
A drawing stopped by the budget is drawn only in part (the page says so).
The per-unit cost of scan work was calibrated in Chromium. I have not measured Firefox or Safari.
I have tried it on only the 34 real drawings I have.

Wrapping up

The viewer runs entirely in the browser: zoom, pan, toggle layers, save a PNG, and print fitted to one A4 or A3 sheet (or save it as a PDF from the print dialog). Files are never sent to a server.

If you find a drawing that freezes it, or an ordinary drawing that gets the "Too many objects" or "outline only" note, I would like to hear about it. Every sample here was written by me, so real drawings surely have shapes I have not met yet.

Article for readers (the viewer is embedded): How to open a .dxf file
Tool: DXF viewer

This article was written with the help of AI (Claude). The code and details come from the actual implementation and were checked before publishing.

The redaction you can't see is still in the text layer

Ren — Thu, 22 Oct 2026 13:57:35 +0000

You have probably heard this story before: someone "redacts" a PDF by drawing black boxes over names, and the names are still there, searchable and copyable, because the box only covers the picture. The text layer underneath never changed.

I found the same bug in my own code, in a document viewer I had written. This post is about what the hole looked like, and what it took to decide, character by character, whether text is actually visible on screen.

Background: a DocuWorks viewer in the browser

The viewer is for DocuWorks documents (.xdw / .xbd). DocuWorks is Fujifilm's document software, common in Japanese offices and local government; think of it as a PDF-like format you receive from a Japanese business partner or city office and cannot open without installing their viewer. My viewer runs entirely in the browser. The reader is ezpzfile-xdw (MIT, written in Rust, not affiliated with Fujifilm) compiled to WebAssembly, and pages are drawn on a canvas. There are two save buttons: "Save as PDF" and "Save the text".

While writing a help article, I read Fujifilm's support note DW10105 (in Japanese). Its title translates to roughly "When a DocuWorks file is converted to PDF, information hidden with annotations can be seen." That made me wonder whether my viewer had the same problem. I built a test document with one line of body text covered by a sticky note and by a black rectangle, and tried it. It did.

What was happening

Here is where the covered line ended up, by output:

Output	Covered line
Screen (canvas)	hidden
"Save as PDF": the page image	hidden
"Save as PDF": the invisible text layer	present
"Save the text"	present

The PDF was built as a page image (a 150 dpi JPEG) with an invisible text layer on top, for search and copy. The image uses the same drawing code as the screen, so the sticky note covers the line. But the text layer contained every piece of text on the page, covered or not. That is the classic black-box redaction failure, produced by my own export.

The people who get hurt are recipients. Someone opens a document they were sent, saves it as a PDF or text, and forwards it. Whatever the sender meant to hide goes along with it, and nobody notices.

Why: text extraction ignores what is drawn on top

A DocuWorks page is a display list: text, shapes, images and annotations (sticky notes, rectangles), drawn in order. The engine's text extraction (text()) and its PDF text layer (toPdf) simply collect every text item in that list. Neither looks at what gets drawn over the text afterwards.

According to DW10105, PDFs made by DocuWorks' own PDF exporter have a related problem: the original text, shapes and images and the annotations pasted on top are separate drawing elements. A slow viewer can show what is under a note for a few seconds, and PDF editing software can expose the covered text. The mechanism differs from mine (theirs keeps the annotations as separate, movable objects; mine put all text into the text layer), but Fujifilm's remedy is the same one I would reach for: produce an image-only PDF.

I could have dropped the text layer entirely. But being able to search a PDF is useful, and most documents have nothing hidden. So I decided to detect whether there is text the screen does not show, and ask before saving only when there is.

Attempt 1: look for what covers each character

The first version was straightforward. For each character, check whether a fill, a thick stroke or an opaque image drawn after it covers it.

Each character is sampled at 3×3 points: 20%, 50% and 80% across and down its box. A character counts as hidden when its centre and at least 7 of the 9 points are unseen, so a stamp over one corner does not count.

const F = [0.2, 0.5, 0.8];
for (const fy of F) for (const fx of F) {
  if (unseen(at, ink, ...point(fx, fy))) {
    hits++;
    if (fx === 0.5 && fy === 0.5) centre = true;
  }
}
if (centre && hits >= HIDDEN_POINTS) mask[n] = true; // HIDDEN_POINTS = 7

The character boxes are placed exactly the way the screen renderer (paint()) places them, because "hidden" should mean hidden on the screen.

Sticky notes, black rectangles, white rectangles, a black highlighter, a thick pen line, an opaque image: every sample I had made was caught.

Attempt 2: text the same colour as what is under it

Code review found shapes this missed. Draw a black rectangle first, then black text on top of it. Black text on a black background. White text on white paper. None of these can be read on screen, yet nothing is drawn over the text, so the check counted zero.

The first one is not contrived. Shade some words black in a word processor to "blank them out", print to DocuWorks, and you can end up with exactly that: black text on a black rectangle.

So I changed the question from "is anything on top of it?" to "can the text colour be told apart from the colour under it at this point?" At each sample point:

Composite everything drawn before the text (white paper, fills, strokes, image pixels) to get the background colour
Lay everything drawn after the text over both the text colour and the background
If the two colours differ by 60 or less (the sum of the absolute R, G and B differences, 0 to 765), the point is unseen

let under: Rgb = [255, 255, 255]; // white paper
let top = ink;                     // the text colour
for (const p of paintsNearThisPoint) {          // in drawing order
  const e = p.at_(x, y);
  if (!e) continue;
  under = blend(under, e);
  if (p.at > run) top = blend(top, e);          // paint after the text lands on the text too
}
return diff(top, under) <= CONTRAST;            // CONTRAST = 60

Attempt 1 turns out to be a special case of this: when an opaque fill lands on top, top and under become the same colour and the difference is 0.

Blending follows canvas. A highlighter is drawn with multiply, so black text under a yellow highlighter stays black and is not counted. Under a black highlighter it is black on black and is hidden. Translucent images are mixed by their opacity.

Some covers are made of glyphs: a run of █ typed over the text. Unicode's Block Elements (U+2580 to U+259F) define which part of the character cell they fill, so I treat each one as a filled rectangle. ■ (U+25A0) is a centred square, 0.1 to 0.9 of the box both ways. In both cases I measured the positions in Chromium with the viewer's fonts. A line covered with ▀ (upper half only) or ▓ (dark shade) is still readable on screen, and the check agrees.

The threshold of 60 is checked against pixels

I did not pick 60 by eye. Separately from the check, I wrote a script that compares pixels. It renders the page twice with the same paint(), once with a given text item and once without it, and if no pixel inside the character's box differs by more than 60 (the same three-channel sum), that character is not visible on screen. It redraws the page once per text item, so it is far too slow for the viewer; it is the ruler I measure the check against.

To pin down the boundary, I made samples whose colour difference is exactly 60 and 63, in three arrangements:

Sample	Difference	Check	Pixel comparison
#ebebeb text on white paper	60	hidden	hidden
#eaeaea text on white paper	63	visible	visible
#141414 text on a black rectangle	60	hidden	hidden
#151515 text on a black rectangle	63	visible	visible
#141414 highlighter over black text	60	hidden	hidden
#151515 highlighter over black text	63	visible	visible

A #202020 highlighter (a difference of 96 from black text) still lets you read the text in a photo of the screen, and the check says "visible".

"Unknown" is not "none"

The check runs over every page in a Web Worker right after the document opens. Each page answers with either "N characters, K hidden" or "could not be read", and a pure function sums up the document:

export function summarizeChecks(checks: PageCheck[]): HiddenSummary {
  const perPage: number[] = [];
  for (const c of checks) {
    if ('unreadable' in c) return { kind: 'unknown' };
    perPage.push(c.hidden);
  }
  const chars = perPage.reduce((a, b) => a + b, 0);
  return chars
    ? { kind: 'found', pages: perPage.filter((k) => k > 0).length, chars, perPage }
    : { kind: 'none' };
}

It did not start out like this. A page where the engine stopped (a WebAssembly trap) used to be added as "0 hidden". Code review caught that too. Adding it as 0 makes the whole document "none", and the viewer would save with text without asking. A page that could not be read is precisely the page whose contents you do not know, so one unreadable page makes the whole document "unknown".

The same rule applies elsewhere. If the caller forgets to pass the pixels of an image the check needs, it throws, which ends in "unknown". An image that is itself broken and cannot be decoded, on the other hand, covers nothing: it is not drawn on screen or in the PDF image either, so it really does not hide anything.

The UI keeps four states: checking, unknown, none, found. "Unknown" never looks the same as "none".

A notice on open, a dialog before saving

When the result is "found", a yellow notice appears right after the document opens:

Some text can't be seen on screen, for example because it is under sticky notes or filled shapes (22 characters on 1 page). When you save a PDF or the text, you can choose whether to include it.

Pressing a save button always uses the check's result. If the background check ended in "unknown", it runs once more. If there is hidden text, a dialog asks:

PDF: Save image-only PDF (primary) / Save with text / Cancel
Text: Save hidden text as ■ (recommended) / Save everything / Cancel

The tool cannot know whether the hiding was intentional. Some people just stick a note over their own scribbles. So I kept every choice, made the option that keeps hidden text out the primary button, and put the initial focus on it.

When the check could not be completed, the dialog says "Couldn't check for hidden text". For text, there is then no way to know which characters to replace with ■, so the only choices are "Save everything" and "Cancel". In that case the initial focus goes to Cancel, so pressing Enter does not save everything.

The image-only PDF is just one 150 dpi JPEG per page, drawn by the same paint() as the screen, with no text layer. Writing the PDF by hand took about 70 lines.

The ■ text cannot be made by rewriting the engine's text() output afterwards, because a plain string does not tell you which character came from which display item. I reimplemented the engine's text assembly in JavaScript (a new line when the baseline moves or the text is rotated, a space where items on a line are apart), and a test checks that without masking it matches the engine's text() character for character on every page of every sample.

Known limits

The check does not agree with the pixel comparison perfectly. Running about 60 samples through the same script, most disagreements were "the check says hidden, the pixels show a few visible pixels":

characters at the edge of a cover that only covers the left part of a line
covers made of a run of █ (thin gaps remain between glyphs)
a black bar covering 70 to 80% of the line height (the top edge of the characters peeks out)

Those over-count, so the cost is an extra notice and dialog. A few disagreements go the other way: the pixels say hidden, the check says visible. A hyphen in the shadow of a bar covering about half the line, and one character under a cover of bold ■. In each case, the other characters on the same line are readable on screen.

Things it does not look at:

text cut away by its own clip, and text too small to be drawn
dashed lines (they have gaps, so they do not count as covers)
"text" inside scanned images (it was never in the text layer, so it is out of scope)
fine detail in images (JPEG images are scaled down to 1,024 pixels on the long side before their pixels are read)

So the notice says what it found. It never says "no hidden text".

If you are the one sending the document

This check is a safety net for recipients, so they do not leak something by accident. It does not make the sender's redaction reliable. If you need to hide part of a document before sharing it, do not stop at drawing notes or boxes over it. Convert it to an image-only PDF first, as DW10105 recommends; in DocuWorks that is the image PDF output (画像PDF出力) of DocuWorks PDF, or the convert-to-image plug-in (画像に変換) in DocuWorks Desk. The same applies to any format: flatten to pixels, or use a real redaction tool that removes the text. Before you send it, search the finished PDF for the words you hid and make sure nothing comes up.

Wrapping up

The in-browser DocuWorks viewer now warns about hidden text and can save an image-only PDF or text with ■ in place of hidden characters. Files are never sent to a server.

If you find a way of covering text that the check misses, or a normal document where the notice shows up for no reason, I would like to hear about it. Every sample I tested with was built from scratch, so there are surely real-world covering methods I have not met yet.

Article for readers (the viewer is embedded): How to open an .xdw file
Tool: DocuWorks viewer

This article was written with the help of AI (Claude). The code and details come from the actual implementation and were checked before publishing.

Writing a TNEF parser so winmail.dat never leaves the browser

Ren — Tue, 20 Oct 2026 01:00:20 +0000

If you have ever received an email from Outlook with an attachment called winmail.dat, you know the feeling: no usable extension, nothing opens it, no hint of what is inside. When I went looking for a converter, every one I found said the same thing first: "upload your file to our server."

A winmail.dat is, by definition, an email somebody sent you. It might be a contract or an invoice. Handing it to a site you know nothing about just to find out what is in it gets the order backwards. So I implemented TNEF in TypeScript and made the whole thing run in the browser.

Some background, if you have been lucky enough never to meet it: when Outlook sends a message in Rich Text Format, it does not send normal MIME with normal attachments. It packs the subject, the formatted body, every attachment and a pile of Outlook metadata into one binary blob, encoded as TNEF (Transport Neutral Encapsulation Format), and attaches that as winmail.dat. Outlook on the other end unpacks it silently, so the sender never sees a problem. Everyone else gets the blob.

This post covers the three places where a straightforward implementation breaks, and two problems I only found after shipping: bodies that looked empty, and sender addresses stored in a form you cannot send mail to.

The container itself is simple

signature   uint32   0x223e9f78
key         uint16

repeat until EOF:
  level     uint8    1 = message, 2 = attachment
  attribute uint32   high 16 bits = data type, low 16 bits = attribute id
  length    uint32
  payload   byte[length]
  checksum  uint16

No tree, no index, no offsets to chase. It is a flat run of attribute records, so reading it is a loop. That part worked in an afternoon. The trouble was inside the MAPI property blocks.

1. Everything is 4-byte aligned

String and binary values are length-prefixed, but the length is the number of meaningful bytes, not the number of bytes written. Each value is padded to the next 4-byte boundary.

const len = d.readUint32LE();
const bytes = d.readBytes(len);
d.skip(pad4(len) - len);   // forget this line and everything after it is garbage

The nasty part is how it fails. You do not get a slightly odd filename. The stream slips by one to three bytes, and every property type you read after that is nonsense. It fails silently and completely, which makes it very easy to conclude "this file is corrupt" rather than "my reader is off by two."

2. Named properties have a variable-length header

This one cost me the most time. A property id of 0x8000 or above is a named property, and it is preceded by an extra header that is not mentioned anywhere near the description of the record layout.

if (propId >= 0x8000) {
  d.skip(16);                       // property set GUID
  const kind = d.readUint32LE();
  if (kind === 0) {
    d.skip(4);                      // named by numeric id
  } else {
    const nameLen = d.readUint32LE();
    d.skip(pad4(nameLen));          // named by string; length depends on the name
  }
}

Skip a fixed number of bytes here and it works on your test files, then breaks on somebody's real mail. Same failure as the alignment bug: total desync, no error.

3. Filenames live in four places, in a priority order

This is the one that matters in practice. The same attachment can carry its name in up to four fields, and they do not agree.

const name =
  a.mapiLongFilename ||   // 0x3707, UTF-16LE, full name
  a.mapiFilename ||       // 0x3704
  a.mapiDisplayName ||    // 0x3001
  a.legacyName ||         // attAttachTitle, ANSI, often 8.3
  'attachment';

attAttachTitle sits right next to the attachment bytes, so it is the easiest one to find. But it is an "ANSI" string in whatever legacy code page the sender's Windows used, and it is often truncated to 8.3. On a Japanese system that code page is Shift_JIS (code page 932), the two-byte encoding Windows still uses for non-Unicode text in Japanese locales. A parser that reads only this field produces filenames like 8E9095948E.PDF instead of what the sender typed, which is exactly the mojibake people complain about in winmail.dat tools.

The encoding is declared, not guessed

The encoding of ANSI strings is declared by attribute 0x9007 (the OEM code page): 932 is Shift_JIS, 936 is GBK, 949 is EUC-KR, 950 is Big5, the 125x range is the Windows Latin family, 65001 is UTF-8.

It governs every ANSI string that comes after it, so the parse is order-dependent. You have to read and apply the code page before decoding the subject. Process attributes in whatever order is convenient and you will quietly decode a Japanese subject line as Windows-1252.

Found later: the body often exists only as compressed RTF

For a while after launch, many winmail.dat files showed up as "no body". The body was there. It was stored as Outlook's compressed RTF (PR_RTF_COMPRESSED, 0x1009), and in a winmail.dat that is often the only copy of the body.

The compression (MS-OXRTFCP) is a small LZ77 variant. Its 4,096-byte circular dictionary starts out holding 207 bytes of common RTF:

// MS-OXRTFCP 2.1.2.1
const RTF_DICTIONARY_PREFIX =
  '{\\rtf1\\ansi\\mac\\deff0\\deftab720{\\fonttbl;}{\\f0\\fnil \\froman \\fswiss \\fmodern \\fscript ' +
  '\\fdecor MS Sans SerifSymbolArialTimes New RomanCourier{\\colortbl\\red0\\green0\\blue0\r\n' +
  '\\par \\pard\\plain\\f0\\fs20\\b\\i\\u\\tab\\tx';

Each bit of a control byte says whether the next token is a literal byte or a reference into the dictionary, eight tokens per control byte. A reference can read into the very bytes it is writing, so the copy has to go one byte at a time. The compressed data carries a CRC, so you know it is damaged before you decompress it.

The RTF that comes out is usually not RTF anyone wrote. When Outlook stores an HTML message this way, it wraps the HTML in RTF (MS-OXRTFEX). The tags go into {\*\htmltag …} groups, and whatever Outlook added for RTF readers sits between \htmlrtf and \htmlrtf0. Drop that part, join the rest, and the original HTML comes back. It then goes through the same treatment as any other HTML body from a stranger: sanitized with DOMPurify against an allowlist, and rendered in a sandboxed iframe whose content security policy blocks network loads, so remote tracking images never fire.

The encoding lesson applies here too. The RTF declares its own code page (\ansicpg932), and a double-byte character arrives as two separate escapes, \'82\'a0. If you decode each escape on its own, you get garbage; collect the bytes first and decode them together.

Also found later: the sender's address is stored in a form you cannot send to

Since winmail.dat is created by the sender's Outlook settings, the recipient cannot stop it from happening. So under the result I show a short "here is what to ask the sender" message and a mailto: link that opens it in the user's mail app. I wanted the sender's address in the To field. That turned out to be harder than it sounds.

The sender is recorded in two places:

MAPI sender properties (PidTagSenderName / PidTagSenderEmailAddress, plus the PidTagSentRepresenting… pair for sending on behalf of someone)
The TNEF attribute attFrom (MS-OXTNEF 2.1.3.3.3): an 8-byte header (0x0004, the structure's length, the name's length, the address's length), then the name, then the address as type:address, then 8 zero bytes

For mail sent from inside an Exchange organization, both addresses are often X.500 paths like EX:/O=EXCHANGELABS/OU=…/CN=RECIPIENTS/CN=…. No mail app can send to that. The internet address lives in yet another pair of properties: PidTagSenderSmtpAddress (0x5D01) and PidTagSentRepresentingSmtpAddress (0x5D02).

// Use the first candidate that is an internet address.
const isInternetAddress = (a: string) => /^[^\s@/<>]+@[^\s@<>]+$/.test(a);
const address = [smtp, mapiEmail, attFromEmail].find(isInternetAddress);

If only the X.500 path exists, the From line still shows it (that is what the file holds), but the mailto: link leaves the To field empty for the user to fill in.

Delegated sending adds one more trap. When an assistant sends on behalf of their manager, the "sender" and "sent representing" names differ. Name and address have to come from the same person, or you build a recipient with the manager's name and the assistant's address. The name in attFrom is ANSI, so characters can arrive as ?; I only compare names when both are readable.

Wrapping up

The result is a winmail.dat viewer that runs entirely in the browser. You can check that nothing is uploaded: open the Network tab in your browser's developer tools and convert a file.

It does not yet extract emails attached inside the winmail.dat, or OLE objects.

If you have a winmail.dat it opens wrong, I would like to hear about it. This format has more corners than one person's inbox can cover.

Tool: winmail.dat viewer
For non-developers (the viewer is embedded in the article): How to open winmail.dat
The longer write-up (HTML sanitizing, what is not supported): Writing a TNEF parser so winmail.dat never leaves the browser

This article was written with the help of AI (Claude). The code and details come from the actual implementation and were checked before publishing.