DEV Community: Meltem İntepeler

Six SheetJS details that matter when you convert Excel to CSV

Meltem İntepeler — Thu, 24 Sep 2026 11:17:05 +0000

I build Filewhisk, a set of file tools that run entirely in the browser, and this week I added Excel to CSV, Excel to JSON and CSV to Excel on top of SheetJS 0.20.3. SheetJS is excellent and I'd use it again. But it is a faithful parser, not an opinionated converter. Several of its defaults are correct for a library and wrong for a person who just wants their spreadsheet in another format.

To avoid testing SheetJS against itself, I built the test workbook without it. I wrote the SpreadsheetML by hand with Python's zipfile, so I knew exactly which bytes were in every cell, and I read the output back with xml.etree. Here is what came out.

1. A formula with no cached result can come back as `0`

An .xlsx cell with a formula normally stores the last calculated result next to it:

<c r="J2"><f>C2*2</f><v>6.28318</v></c>

Files written by scripts and reporting tools often leave the result out, because they never ran a calculation engine:

<c r="J3"><f>C3*2</f></c>

With default options SheetJS simply doesn't create that cell, and sheet_to_json gives null. That's fine. But I needed cellStyles: true, because it's the option that gives you hidden rows and columns (!rows, !cols). With it on, the same cell appears as:

{ t: 'z', f: 'C3*2', v: 0 }

sheet_to_json and sheet_to_csv still skip it. Any code that reads cell.v directly, which you will do the moment you care about formats, gets a zero. In a totals column that looks exactly like real data. I check for it explicitly:

if (cell.t === 'z' || cell.v === undefined || cell.v === null) {
  if (cell.f) noCache.push(ref);   // report it, don't invent a value
  return null;
}

2. `.w` is what Excel shows, not what the cell holds

With cellNF: true, each numeric cell carries both the stored value v and the formatted text w:

Cell	`v`	`z` (format)	`w`
C2	3.14159	`0.00`	`3.14`
B5	1234567890123	`General`	`1.23457E+12`
D2	1234.5	`"$"#,##0.00`	`$1,234.50`

Using w reproduces exactly what Excel's own Save As → CSV does. Microsoft's documentation says the CSV format saves "only the text and values as they are displayed in cells of the active worksheet". So 3.14159 leaves as 3.14 and the 13-digit ID leaves in scientific notation. I write v, and I report every cell where w would have rounded.

Telling rounding apart from formatting was trickier than I expected. 2.50 vs 2.5 and $1,234.50 vs 1234.5 lose nothing; 3.14 vs 3.14159 does. I strip currency symbols, thousands separators and a trailing % from w, parse what's left, and compare numerically.

One exception: a zero-padding format such as 00000 on the stored number 721. There the displayed 00721 is the data (a postcode), so I write w.

3. `String(v)` adds noise Excel never shows

String(0.1 + 0.2)   // "0.30000000000000004"

Excel keeps 15 significant digits and displays 0.3. Writing JavaScript's full representation into a CSV puts noise into every column of calculated values. I round to Excel's precision first:

const excelNumber = (v) => String(parseFloat(v.toPrecision(15)));

4. Dates: skip `cellDates` and parse the serial yourself

With cellDates: true, a date cell comes back as a JS Date set to midnight UTC. toISOString() is right, but the local getters are not everywhere. Reading the same 15 March 2024 cell with the process time zone set to America/New_York:

cell.v.toISOString()          // "2024-03-15T00:00:00.000Z"
cell.v.getDate()              // 14
cell.v.toLocaleDateString()   // "3/14/2024"

Anyone west of UTC who formats with the usual local methods gets the day before. I keep cellDates: false, detect date formats with XLSX.SSF.is_date(cell.z), and split the serial into components with no time zone involved:

const p = XLSX.SSF.parse_date_code(cell.v, { date1904 });
const iso = `${p.y}-${pad(p.m)}-${pad(p.d)}`;

date1904 comes from wb.Workbook.WBProps.date1904. Workbooks from old Mac versions of Excel count days from 1904. Forget it and every date is four years and one day early.

5. Text containing `_x0041_` is written unescaped

This one surprised me most. OOXML uses _xHHHH_ to escape characters XML can't carry. A carriage return inside a cell is written as _x000D_. That means a literal _x0041_ in your data has to be written as _x005F_x0041_, with the underscore escaped.

SheetJS doesn't do that when writing. I wrote a cell containing a_x0041_b, and SheetJS itself read it back as:

aAb

That's what the spec says a reader should do with an unescaped _x0041_, so other readers will do the same. It's rare in real data, but when it happens it silently changes a value. The fix before writing:

const protect = (s) => s.replace(/_x([0-9A-Fa-f]{4})_/g, '_x005F_x$1_');

While I was there, I also switched on bookSST: true. By default SheetJS writes text cells as t="str", a type the spec defines for formula results. The shared-strings table (t="s") is how Excel itself stores text, so that's what the files use now.

6. The mini build can't read `.xls`

xlsx.mini.min.js is 280 KB, against 952 KB for the full build, so I wanted it for everything. It writes XLSX fine. It can't read legacy .xls or .xlsb:

parse_xlscfb is not defined
parse_sty_bin is not defined

I load the mini build for CSV → Excel and the full build for the two reader pages. Both are lazy-loaded when the first file is dropped, so neither page pays for them on page load.

The CSV → Excel direction has its own traps

Going the other way, the enemy is Excel's type guessing when you open a CSV. 00721 becomes 721, a 16-digit ID keeps only 15 digits, and MARCH1 becomes a date. Rather than write cells one at a time, I analyse each column first. If any value in a column has a leading zero or more than 15 significant digits, the whole column is written as text. Otherwise half a postcode column becomes numbers, and sorting and lookups break. Only unambiguous ISO dates (2024-03-15) become real dates. Anything starting with =, +, - or @ is stored as a text cell, so it can't run as a formula.

How I tested it

Test workbooks come from a small Python script that writes SpreadsheetML by hand, so SheetJS is never both the writer and the reader.
The .xlsx files the tool produces are unzipped and parsed with xml.etree, with _xHHHH_ decoded as ECMA-376 specifies. I check cell types, number formats, autofilter ranges and sheet names from the XML itself.
CSV output goes through Python's csv module.

That's 89 assertions across the three pages. The problem in section 5 turned up because the test read the XML itself instead of asking SheetJS: SheetJS reads its own output back as aAb without complaint.

If you'd like to see it working: Excel to CSV, Excel to JSON and CSV to Excel. Everything runs in the browser, and the report under each conversion lists every cell it treated differently from Excel.

Your PDF image extractor is probably re-encoding every JPEG. Here's how to get the original bytes

Meltem İntepeler — Tue, 15 Sep 2026 10:43:42 +0000

Most "extract images from PDF" code I found online does the same thing: render or decode each image, draw it onto a canvas, and call canvas.toBlob(). It works, and every photo you get back has been through a second round of lossy compression, even when the PDF was holding a perfectly good JPEG file all along.

I build Filewhisk, a set of file tools that run entirely in the browser, and I wanted the PDF image extractor to hand back the images exactly as they are stored. This post covers the three paths I ended up with, the canvas behaviour that made me write my own PNG encoder, and how I matched my own PDF parsing with pdf.js for the formats I didn't want to decode myself.

A JPEG inside a PDF is already a JPEG file

PDF stores images as stream objects. When a stream's filter is DCTDecode, its data is a JPEG bitstream: you can write the bytes to disk with a .jpg extension and open them. No decoding, no quality setting, no loss.

With pdf-lib, finding them looks like this:

import { PDFDocument, PDFName, PDFRawStream } from 'pdf-lib';

const doc = await PDFDocument.load(bytes);
const N = (name) => PDFName.of(name);

for (const [ref, obj] of doc.context.enumerateIndirectObjects()) {
  if (!(obj instanceof PDFRawStream)) continue;
  if (obj.dict.get(N('Subtype')) !== N('Image')) continue;
  if (obj.dict.get(N('Filter')) === N('DCTDecode')) {
    const jpeg = new Blob([obj.contents], { type: 'image/jpeg' });
  }
}

(PDFName.of returns the same object for the same name, so === works.)

In my tests the extracted bytes were identical to the JPEG that went into the PDF, byte for byte. But "has a DCTDecode filter" is not the same as "these bytes are the picture you see". I only take the raw bytes when all of these are true:

No /SMask. Transparency is stored as a separate grayscale image. The JPEG alone is the photo with its transparent areas filled in, often black.
No /Decode array. It remaps sample values. Some CMYK JPEGs from Adobe apps are stored inverted and fixed up by /Decode [1 0 1 0 1 0 1 0]. The raw file looks like a photo negative.
Gray or RGB colour space. A CMYK JPEG is a valid file, but many viewers show it with odd colours.
No /Mask (colour-key transparency).
The filter is only DCTDecode. Filter can also be an array, such as [/FlateDecode /DCTDecode].

Everything that fails these checks goes down one of the other two paths.

Don't use `enumerateIndirectObjects` to decide what to extract

The loop above is fine for a demo, but it returns every image object in the file. That includes images no page ever draws: leftovers from earlier edits, alternates, and the soft masks themselves. Users expect "the pictures in my document".

So I read each page's content stream and follow the drawing operators instead. The parts that matter are small:

q / Q push and pop the graphics state
a b c d e f cm multiplies the current transformation matrix (CTM)
/Name Do draws an XObject from the page's resources. If it's a Form XObject, recurse into its content with its /Matrix; if it's an image, record it.
BI … ID … EI is an inline image, whose binary data you have to skip without tokenising it

The same pass gives you something useful for free. An image is drawn into the unit square, so the CTM tells you how large it is printed:

const widthInches  = Math.hypot(ctm[0], ctm[1]) / 72;   // PDF units are 1/72 inch
const heightInches = Math.hypot(ctm[2], ctm[3]) / 72;
const dpi = Math.min(pixelWidth / widthInches, pixelHeight / heightInches);

An 800×600 photo placed four inches wide is 200 DPI. Showing that number next to each image answers the most common complaint about extractors ("why is my image blurry?") before anyone asks it: the PDF only contained a small image.

The pass also gives each page its images in drawing order, which becomes important in a moment.

Lossless images: why I didn't use canvas for PNG

Flate-compressed images are raw pixel rows, which is easy to decode:

Inflate the stream (I use fflate).
Undo the PNG predictor if /DecodeParms has Predictor >= 10.
For /Indexed colour spaces, expand each index through the lookup table.
If there is an /SMask with the same dimensions, decode it the same way and use it as the alpha channel.

The obvious way to produce a PNG from that is putImageData and then toBlob('image/png'). PNG is lossless, so that should be safe. It isn't, for images with partial transparency.

A 2D canvas stores pixels with premultiplied alpha, so the colour of a semi-transparent pixel loses precision on the way in. I measured a putImageData → getImageData round trip in Chrome 153:

Written (R, G, B, alpha)	Read back
200, 100, 50, 255	200, 100, 50, 255
200, 100, 50, 128	199, 100, 50, 128
200, 100, 50, 10	204, 102, 51, 10
200, 100, 50, 3	170, 85, 85, 3
200, 100, 50, 1	255, 0, 0, 1

Across 40 colours and every alpha from 1 to 254, 7,630 of 10,160 semi-transparent pixels came back different. On screen it's barely visible. But the anti-aliased edges of a logo are exactly those pixels, and the whole point of the tool was "exactly as stored".

Writing a PNG yourself turns out to be about 40 lines, because fflate does the compression:

const CRC = new Uint32Array(256).map((_, n) => {
  let c = n;
  for (let k = 0; k < 8; k++) c = c & 1 ? 0xEDB88320 ^ (c >>> 1) : c >>> 1;
  return c >>> 0;
});

function crc32(bytes) {
  let c = 0xFFFFFFFF;
  for (const b of bytes) c = CRC[(c ^ b) & 255] ^ (c >>> 8);
  return (c ^ 0xFFFFFFFF) >>> 0;
}

function chunk(type, payload) {
  const out = new Uint8Array(12 + payload.length);
  const view = new DataView(out.buffer);
  view.setUint32(0, payload.length);
  for (let i = 0; i < 4; i++) out[4 + i] = type.charCodeAt(i);
  out.set(payload, 8);
  view.setUint32(8 + payload.length, crc32(out.subarray(4, 8 + payload.length)));
  return out;
}

// channels: 1 = gray, 2 = gray + alpha, 3 = RGB, 4 = RGBA (8 bits each)
function encodePng(pixels, width, height, channels) {
  const colorType = { 1: 0, 2: 4, 3: 2, 4: 6 }[channels];
  const rowLen = width * channels;
  const raw = new Uint8Array((rowLen + 1) * height);   // first byte of each row: filter 0
  for (let y = 0; y < height; y++) {
    raw.set(pixels.subarray(y * rowLen, (y + 1) * rowLen), y * (rowLen + 1) + 1);
  }
  const header = new Uint8Array(13);
  const hv = new DataView(header.buffer);
  hv.setUint32(0, width);
  hv.setUint32(4, height);
  header[8] = 8;          // bit depth
  header[9] = colorType;
  return new Blob([
    new Uint8Array([137, 80, 78, 71, 13, 10, 26, 10]),
    chunk('IHDR', header),
    chunk('IDAT', fflate.zlibSync(raw, { level: 6 })),
    chunk('IEND', new Uint8Array(0)),
  ], { type: 'image/png' });
}

Two side benefits: a grayscale image stays a grayscale PNG instead of tripling in size as RGBA, and no canvas is involved, so iOS Safari's canvas size limit doesn't stop you on a large scan.

Everything else: let pdf.js decode it

That leaves CMYK images, JPEG 2000, the black-and-white fax formats scanners love (CCITT and JBIG2), 1-bit images and anything with a /Decode array. Writing decoders for all of those was not a good use of my time. pdf.js already decodes every one of them, and it converts CMYK the way a PDF viewer shows it.

pdf.js doesn't work in terms of PDF object references, though. You ask for a page's operator list and get opaque image ids:

const page = await pdf.getPage(pageNumber);
const list = await page.getOperatorList();

const paints = [];
list.fnArray.forEach((fn, i) => {
  if (fn === pdfjsLib.OPS.paintImageXObject) {
    const [id, width, height] = list.argsArray[i];
    paints.push({ id, width, height });
  } else if (fn === pdfjsLib.OPS.paintImageXObjectRepeat) {
    paints.push({ id: list.argsArray[i][0] });   // same image drawn several times in a row
  }
});

To get an image's pixels, ask the page's object store and wait for the callback, since the object may not have arrived from the worker yet. Ids that start with g_ live in page.commonObjs instead of page.objs:

function getImage(page, id) {
  const store = id.startsWith('g_') ? page.commonObjs : page.objs;
  return new Promise((resolve) => store.get(id, resolve));
}

What comes back is either { bitmap, width, height } (an ImageBitmap decoded in the worker) or { data, width, height, kind } with a raw buffer, where kind is 1 for 1-bit gray (bit set = white), 2 for RGB and 3 for RGBA. I handle both and hand the result to the same encodePng. A bitmap can only be read back through a canvas, so the premultiplied-alpha rounding from the previous section does apply on this path when the image has partial transparency. I accept that for these formats; in my test files the images that ended up here were opaque, and for those the round trip is exact.

The remaining problem is mapping a pdf.js id back to the PDF object the rest of my code knows about. This is where the drawing order from the content-stream pass pays off:

On a page, take my list of drawn images (without image masks, which pdf.js paints with a different operator) and pdf.js's paintImageXObject calls.
If both lists are the same length, pair them by position.
Accept a pair only if pdf.js's width and height match the image object's /Width and /Height.
If anything doesn't line up, try another page that draws the same image. If none works, count the image as "could not decode" instead of guessing.

For JPEG 2000, JBIG2 and CCITT, pdf.js 6 loads its decoders as separate files (openjpeg.wasm, jbig2.wasm, plus plain-JavaScript fallbacks) from the folder you pass as wasmUrl to getDocument. If you self-host pdf.js, copy that wasm/ folder too and set the option.

Testing notes

Compare bytes, not file names. The JPEG test embeds a known JPEG with pdf-lib, extracts it and compares every byte with the original.
Build the awkward PDFs yourself. pdf-lib can register raw image streams, so a test can create a grayscale Flate image, an /Indexed image with a four-colour palette and a 1-bit checkerboard, then check exact pixel values in the output.
Include an image that is never drawn. Register an image in a page's resources without a Do for it, and assert that it doesn't show up.
Deduplicate by content, not by reference. Merged PDFs often embed the same logo once per page. I hash the extracted bytes or pixels and show one card listing every page the image appears on.

Takeaways

A DCTDecode stream is a JPEG file. Save it as-is unless it has a soft mask, a /Decode array, a colour-key mask or a CMYK colour space.
Walk the content streams to find the images a page actually draws, and use the CTM to report the DPI each one is printed at.
putImageData / toBlob is not a lossless path for semi-transparent pixels. Writing a PNG with fflate is short.
Let pdf.js decode the formats you don't want to own, and match its images to yours by drawing order, checked by dimensions.

The extractor linked at the top runs this setup, and the PDF never leaves the browser.

canvas.toBlob('image/avif') silently returns a PNG. Here's how I shipped AVIF export anyway

Meltem İntepeler — Sun, 13 Sep 2026 11:11:07 +0000

If you have ever written canvas.toBlob(callback, 'image/avif'), there is a good chance your users have been downloading PNG files with an .avif name.

That is what happened to me. I build Filewhisk, a set of image tools that run entirely in the browser, and two of its pages were supposed to convert JPG and PNG to AVIF. The encoder was the browser's own canvas. I believed Chrome had been able to encode AVIF for years. It can't, and neither can any other major browser.

This post covers how I found out, how to detect it properly, and the four traps I hit while shipping AVIF export with a WebAssembly encoder instead.

`toBlob` does not fail. It falls back.

The canvas spec says that if the browser does not support the requested type, it must return a PNG. No exception, no rejected promise, just a different blob.type.

So I measured it on Chrome 153:

const canvas = document.createElement('canvas');
canvas.width = canvas.height = 16;

canvas.toBlob(b => console.log(b.type), 'image/avif');
// image/png

const oc = new OffscreenCanvas(16, 16);
oc.getContext('2d');
console.log((await oc.convertToBlob({ type: 'image/avif' })).type);
// image/png

Both paths return PNG. There is a long-standing Chromium issue for exactly this (40848792, "Canvas.toBlob cannot encode AVIF"), and Firefox and Safari do not encode AVIF from a canvas either. Where did my belief come from? Chrome 85 added AVIF decoding. Displaying a format and producing it are different features, and I had merged them in my head.

My tool did one thing right: it checked blob.type before offering a download, so users got a "not supported" message instead of a mislabelled PNG. But that also meant two pages could not do the one thing their titles promised.

Detect it, don't assume it

If you use canvas encoding for anything other than PNG, test the actual output type once:

function canEncode(mime) {
  return new Promise(resolve => {
    const c = document.createElement('canvas');
    c.width = c.height = 1;
    c.toBlob(blob => resolve(!!blob && blob.type === mime), mime, 0.8);
  });
}

WebP passes this test in Chromium browsers. AVIF passes nowhere today.

The fix: libavif compiled to WebAssembly

Sending the image to a server was not an option, because "your files never leave your device" is the whole point of the site. So the encoder had to run in the browser.

jSquash packages the codecs from Google's Squoosh app for use in the browser, including an AVIF encoder built from libavif (@jsquash/avif, Apache-2.0). It works well. Getting it into a plain static site without a bundler took more care than I expected.

Trap 1: the multi-threaded build needs cross-origin isolation

The package ships a single-threaded and a multi-threaded encoder. The multi-threaded one is faster, but it relies on SharedArrayBuffer, which requires the page to be cross-origin isolated (Cross-Origin-Opener-Policy and Cross-Origin-Embedder-Policy headers). Those headers block cross-origin resources that don't opt in, and third-party scripts like ad and analytics tags generally don't. For an ad-supported site that is a non-starter, so I used the single-threaded build only.

Trap 2: the convenience wrapper assumes a bundler

The package's encode.js imports a bare specifier (import { threads } from 'wasm-feature-detect') and, when threads are available, switches to the multi-threaded build. Without a bundler or an import map, a bare specifier simply fails to load. I skipped the wrapper and imported the compiled single-threaded codec directly: codec/enc/avif_enc.js, which loads its .wasm file relative to import.meta.url.

Trap 3: encoding blocks the page, so use a module worker

A 1600×719 photo takes about 1.3 to 1.7 seconds to encode on my machine. On the main thread that is a frozen page. The encoder module works fine inside a module worker:

// avif-worker.js
import createModule from './avif_enc.js';

const DEFAULTS = {
  quality: 50, qualityAlpha: -1, denoiseLevel: 0, tileColsLog2: 0,
  tileRowsLog2: 0, speed: 6, subsample: 1, chromaDeltaQ: false,
  sharpness: 0, tune: 0, enableSharpYUV: false, bitDepth: 8, lossless: false
};

let modulePromise = null;

self.onmessage = async ({ data: msg }) => {
  try {
    modulePromise ??= createModule({ noInitialRun: true });
    const mod = await modulePromise;
    const out = mod.encode(new Uint8Array(msg.pixels), msg.width, msg.height,
                           { ...DEFAULTS, ...msg.options });
    if (!out) throw new Error('AVIF encoding failed');
    const buffer = out.slice().buffer;
    self.postMessage({ id: msg.id, buffer }, [buffer]);
  } catch (err) {
    modulePromise = null;
    self.postMessage({ id: msg.id, error: String(err?.message ?? err) });
  }
};

On the page, draw the image to a canvas, take the RGBA pixels and transfer the buffer instead of copying it:

const worker = new Worker('/vendor/avif-2.1.1/avif-worker.js', { type: 'module' });

function encodeAvif(canvas, quality) {
  const { data } = canvas.getContext('2d')
    .getImageData(0, 0, canvas.width, canvas.height);
  return new Promise((resolve, reject) => {
    const id = crypto.randomUUID();
    const onMessage = ({ data: msg }) => {
      if (msg.id !== id) return;
      worker.removeEventListener('message', onMessage);
      msg.error ? reject(new Error(msg.error))
                : resolve(new Blob([msg.buffer], { type: 'image/avif' }));
    };
    worker.addEventListener('message', onMessage);
    worker.postMessage(
      { id, pixels: data.buffer, width: canvas.width, height: canvas.height,
        options: { quality } },
      [data.buffer]
    );
  });
}

Two more details. Listen for the worker's error event and reject pending jobs, otherwise a failed download leaves promises hanging forever. And keep using the native path first: if canEncode('image/avif') ever returns true, skip the worker entirely.

The encoder is about 3.5 MB of WebAssembly (roughly 1 MB over the wire with Brotli). It is only fetched the first time someone actually converts to AVIF, so the rest of the page pays nothing.

Trap 4: files loaded by the worker can't be cache-busted

My build appends a content hash to script URLs (toolkit.js?v=1a2b3c4d) so that a deploy never serves stale JavaScript. That works for the worker URL itself, which I stamp at build time. But the worker then loads avif_enc.js and avif_enc.wasm by relative path, and those requests cannot carry my hash. The fix is boring and reliable: put the encoder in a versioned folder (vendor/avif-2.1.1/) and treat it as immutable. Upgrading means a new folder, never overwriting the old one.

Mapping a "quality" slider to AVIF

The tool's quality menu is on a JPEG-style scale (95, 85, 75, 60), but libavif's quality value means something different: the same number compresses much harder. I measured file size and PSNR against the source on a real 1600×719 landscape photo and chose a mapping where AVIF comes out smaller than JPEG without falling behind it on PSNR:

Setting	JPEG	AVIF (libavif quality)
95	443 KB, 37.5 dB	209 KB, 37.8 dB (80)
85	230 KB, 34.5 dB	133 KB, 36.2 dB (64)
75	165 KB, 33.4 dB	84 KB, 34.5 dB (52)
60	121 KB, 32.4 dB	39 KB, 32.1 dB (38)

One warning from the process: my first calibration used a synthetic noisy texture, and AVIF appeared to fall off a cliff at the medium setting (102 KB down to 14 KB). It was simply discarding the artificial noise. Calibrate codecs on real photos.

Testing notes

A few things that cost me time and might save you some:

Check the output bytes, not the MIME type you assigned. A real AVIF file has ftypavif at bytes 4–11. Decode it back with createImageBitmap and compare a few pixels, including alpha if the source had transparency.
Module workers must be same-origin. I originally tested the live site by loading its HTML from a local server with a <base href> pointing at production. Scripts loaded fine, but the worker resolved to another origin and the browser refused it, which looked exactly like a broken deploy. Test worker-based pages on their real origin.
Headless screenshots can lie about WebAssembly. Chrome's --screenshot with --virtual-time-budget did not wait for WASM compilation, so every screenshot captured the page before the result existed. Driving the page through the DevTools protocol and waiting for a real "done" signal fixed it.

Takeaways

canvas.toBlob and convertToBlob silently return PNG for unsupported types. Always check blob.type.
No major browser encodes AVIF from a canvas today. If you need AVIF output in the browser, bring an encoder.
For sites with third-party scripts, the single-threaded WASM build in a module worker is the practical choice.
Load the encoder lazily, version its folder, and calibrate quality on real images.

If you want to see the result, the JPG to AVIF converter linked at the top of this post runs exactly this setup. The image never leaves your browser.

DEV Community: Meltem İntepeler

Six SheetJS details that matter when you convert Excel to CSV

1. A formula with no cached result can come back as 0

2. .w is what Excel shows, not what the cell holds

3. String(v) adds noise Excel never shows

4. Dates: skip cellDates and parse the serial yourself

5. Text containing _x0041_ is written unescaped

6. The mini build can't read .xls

The CSV → Excel direction has its own traps

How I tested it

Your PDF image extractor is probably re-encoding every JPEG. Here's how to get the original bytes

A JPEG inside a PDF is already a JPEG file

Don't use enumerateIndirectObjects to decide what to extract

Lossless images: why I didn't use canvas for PNG

Everything else: let pdf.js decode it

Testing notes

Takeaways

canvas.toBlob('image/avif') silently returns a PNG. Here's how I shipped AVIF export anyway

toBlob does not fail. It falls back.

Detect it, don't assume it

The fix: libavif compiled to WebAssembly

Trap 1: the multi-threaded build needs cross-origin isolation

Trap 2: the convenience wrapper assumes a bundler

Trap 3: encoding blocks the page, so use a module worker

Trap 4: files loaded by the worker can't be cache-busted

Mapping a "quality" slider to AVIF

Testing notes

Takeaways

1. A formula with no cached result can come back as `0`

2. `.w` is what Excel shows, not what the cell holds

3. `String(v)` adds noise Excel never shows

4. Dates: skip `cellDates` and parse the serial yourself

5. Text containing `_x0041_` is written unescaped

6. The mini build can't read `.xls`

Don't use `enumerateIndirectObjects` to decide what to extract

`toBlob` does not fail. It falls back.