DEV Community: kyungju lee (Benjie)

Two versions of pdf.js in one bundle: what SVG export actually costs

kyungju lee (Benjie) — Sat, 22 Aug 2026 07:30:31 +0000

A PDF-compatible .ai file is a PDF container, so pdf.js can open it. I use it for exactly that: artboard thumbnails, a preview, PNG export. That path runs on pdf.js 6.2.108.

The SVG export button on the same page runs on pdf.js 3.11.174, loaded under an npm alias:

"pdfjs-dist": "^6.2.108",
"pdfjs-legacy": "npm:pdfjs-dist@3.11.174"

Two copies of the same library, in the same app, at the same time. That is not a decision anyone makes cheerfully, so here is the whole reasoning — plus the three constructor options the 3.x build needs before SVG export produces anything usable, and what shipping the second copy cost in bytes.

I build ArtboardLab, a free browser-based set of design tools where files are never uploaded — everything below came out of making the .ai tools there work on real files.

Why the old version at all

The SVG backend is SVGGraphics, and it only exists on the old line. Grep the shipped bundles:

$ grep -c SVGGraphics node_modules/pdfjs-dist/build/pdf.mjs   # 6.2.108
0
$ grep -c SVGGraphics node_modules/pdfjs-legacy/build/pdf.js  # 3.11.174
7

3.11.174 also still exports it from its type definitions. v6 has no equivalent — there is no "render this page as vector markup" API to migrate to. Either you write a PDF-operator-to-SVG translator yourself, or you keep a build that already has one.

So src/lib/ai/svg-export.ts is the only module in the codebase allowed to import pdfjs-legacy, and it is reached only through await import(...). Everything else — open, thumbnails, preview, PNG — stays on v6.

The three options 3.x needs

Getting SVGGraphics to emit markup for a real designer's .ai file took three constructor options that the sample snippets don't mention. All three are non-optional in the sense that removing any one of them breaks a specific, reproducible class of file:

const task = legacy.getDocument({
  data: new Uint8Array(await file.arrayBuffer()),
  isEvalSupported: false,
  fontExtraProperties: true,
  isOffscreenCanvasSupported: false,
  cMapUrl: '/pdf-assets/cmaps/',
  cMapPacked: true,
  standardFontDataUrl: '/pdf-assets/standard_fonts/',
});

isEvalSupported: false — this build predates the fix for CVE-2024-4367, the font-program-to-eval() path. Nothing about the SVG output depends on this flag; it is here because the input is a stranger's file and font programs must never reach eval(). Worth noting the direction the library went: isEvalSupported appears ten times in the 3.11.174 bundle and zero times in the 6.2.108 one. On the current version there is no flag to forget. On the pinned one there is, and forgetting it is the entire risk of pinning.

fontExtraProperties: true — without it, any file with an embedded font throws in SVGGraphics' font-embedding pass with addFontStyle: No font data available. The translated font data is dropped before the SVG writer can ask for it. Since embedded fonts are the normal case in artwork, this is effectively "SVG export doesn't work" rather than an edge case.

isOffscreenCanvasSupported: false — this one only shows up on files with placed photos. With OffscreenCanvas available, the worker hands images back as ImageBitmap and leaves imgData.data null. SVGGraphics predates bitmaps and reads .data unconditionally, so the first raster image throws null.subarray inside paintInlineImageXObject. I found this on a 24 MB two-artboard file full of placed photos; every text-only test file had passed.

Two more settings live on the SVG path rather than on getDocument:

const gfx = new legacy.SVGGraphics(page.commonObjs, page.objs, true);
gfx.embedFonts = true;

That third positional argument is forceDataSchema. With it, fonts and images are inlined as base64 data: URIs; without it the generated markup referenced blob: URLs scoped to the page session — which look perfect in the tab that produced them and are dead references the moment the .svg is on disk. embedFonts = true inlines the font programs as @font-face so text still renders on a machine that doesn't have the original typeface.

The CJK story is the same as on v6: cMapUrl plus cMapPacked, or Korean, Japanese and Chinese text loses every glyph silently — no error, just empty artwork.

The two copies never touch

The legacy document is opened from scratch: its own module instance, its own GlobalWorkerOptions.workerSrc, its own worker, its own PDFDocumentProxy. Nothing is shared with the v6 pipeline, and that isolation is deliberate — a PDFPageProxy from one build has no business crossing into the other.

One consequence catches you immediately. The SVG path re-reads the File from disk:

data: new Uint8Array(await file.arrayBuffer()),

It cannot reuse the buffer already in memory, because that buffer was transferred to the v6 worker when the document was opened and is therefore detached. Keeping the File handle around and re-reading is the fix; there is nothing clever to do about it.

Concurrent renders on the same page proxy corrupt output

This one belongs to the v6 side, and it is the bug I'd most want to have known in advance.

Thumbnails, the preview render, and the warning scan all want page data at the same time, and the naive version fires them off in parallel. What comes back is all-black canvases — no exception, no console warning, just wrong pixels. Overlapping render() / getOperatorList() calls on the same PDFPageProxy corrupt the output.

The fix is unglamorous: one promise chain, everything through it.

let pageWork: Promise<void> = Promise.resolve();

function enqueue(work: () => Promise<void>): Promise<void> {
  pageWork = pageWork.then(work).catch(() => {});
  return pageWork;
}

The .catch(() => {}) keeps one bad page from breaking the chain for everything queued behind it — which has a consequence worth stating out loud, because it bit me: the queue swallows rejections, so any caller that needs to know whether its work failed has to record that inside the enqueued closure. A try/catch around the await enqueue(...) never fires. PNG export failures were silently invisible for a while for exactly this reason.

The SVG export deliberately stays outside this chain, for both halves of the same reason: it shares no PDFPageProxy with the v6 pipeline, and it needs its rejections to actually surface.

v6 paints the transparent background opaque

Also on the v6 side, and also worth writing down. Passing background: 'rgba(0,0,0,0)' to page.render() produces solid black. So does 'transparent'. So does a transparent CanvasPattern.

Transparency is recovered the old-fashioned way — render the page twice, once on white and once on black, derive per-pixel alpha from the difference, then un-premultiply the black composite:

const diff = (w[i] - b[i] + (w[i+1] - b[i+1]) + (w[i+2] - b[i+2])) / 3;
const alpha = 255 - Math.max(0, Math.min(255, Math.round(diff)));

It doubles the render cost of every thumbnail and every preview, which is why the render queue above matters as much as it does.

Paying for the second copy only when it's used

A second pdf.js is affordable only if it stays out of the initial chunk. Two rules do that: the import is dynamic, and it lives in a module nothing imports eagerly.

The build output shows it working. The svg-export chunk that the island actually references is 1,139 bytes — just the loader. The real weight sits in sibling chunks that no one fetches until the button is clicked:

chunk	bytes
`svg-export.*.js` (loader)	1,139
legacy main bundle	305,393
legacy worker	1,087,212
v6 worker	1,262,398

So a visitor who opens a file and exports PNG never downloads the 1.39 MB legacy pair at all. A visitor who clicks Export SVG pays for it once, on click, with the button already in its loading state.

One last cost that surprised me, since it's downstream of forceDataSchema: base64-inlined images make the markup enormous and highly compressible. The multi-file ZIP path defaults to store-only (level 0), which is correct for PNG and WebP entries and badly wrong here. That photo-heavy two-artboard file produced a ~62 MB store-only ZIP; at DEFLATE level 6 the same two SVGs zipped to 10.2 MB. The ZIP helper now takes an optional level and the SVG path passes 6.

Would I do it again

Yes, but with the pin treated as a liability rather than a dependency. One module may import it, it loads on click only, and the security flag the old build needs is commented at the call site with its CVE number, because the whole hazard of pinning is that the reason gets forgotten before the pin does.

Image codecs in the browser with jSquash: seven decisions the README doesn't make for you

kyungju lee (Benjie) — Fri, 21 Aug 2026 07:38:52 +0000

Squoosh's codecs are published as standalone npm packages under @jsquash/*, and the basic usage really is as short as the README says: give encode() an ImageData, get an ArrayBuffer back. Getting from that snippet to something you can point a stranger's 12-megapixel photo at is where the actual work lives.

I build ArtboardLab, a free browser-based design toolkit where nothing gets uploaded — that's where these lessons came from. The compressor there uses six jSquash packages:

"@jsquash/avif": "^2.1.1",
"@jsquash/jpeg": "^1.6.0",
"@jsquash/oxipng": "^2.3.0",
"@jsquash/png": "^3.1.1",
"@jsquash/resize": "^2.1.1",
"@jsquash/webp": "^1.5.0"

Below are the seven decisions I had to make myself. (One clarification up front, since I mixed these up in an earlier draft of my own docs: WASM here means the image codecs and nothing else. The .ai file tools on the same site run on pdf.js, which is plain JavaScript.)

Single-threaded WASM was a constraint I chose, not one I hit

The multithreaded builds of these codecs need SharedArrayBuffer, which needs cross-origin isolation, which means shipping COOP/COEP headers. On an ad-funded site those headers break AdSense iframes. So the deploy config carries a permanent note instead:

# NOTE: never add COOP/COEP (Cross-Origin-Opener-Policy / Cross-Origin-Embedder-Policy).
# Cross-origin isolation breaks Google AdSense iframes.
# The WASM codecs on this site run single-threaded by design, so they don't need it.

Once that's settled, per-image encode speed is fixed and the only parallelism left is between images: several workers, each with its own independent single-threaded WASM instance. Which turns the problem into a scheduling problem.

Pool size: half the cores, capped at three, one on mobile

export function poolSize(): number {
  const nav = navigator as Navigator & { deviceMemory?: number };
  const cores = nav.hardwareConcurrency || 4;
  const isMobile = /Android|iPhone|iPad|Mobile/i.test(nav.userAgent);
  const lowMemory = nav.deviceMemory !== undefined && nav.deviceMemory < 4;
  if (isMobile || lowMemory) return 1;
  return Math.max(1, Math.min(3, Math.floor(cores / 2)));
}

hardwareConcurrency is the wrong number to use directly. Each worker holds a decoded RGBA buffer plus a WASM heap, so the ceiling that matters is memory, not cores — and the browser tab you're competing with is the user's, on a machine that's also running everything else they had open. Half the cores, hard-capped at three, and a single worker on mobile or anything reporting under 4 GB.

Reserve the worker synchronously, before the file read

This is the ordering the pool's own comment exists to protect. The dispatch loop wants to hand a worker some bytes, and reading those bytes is async:

const slot = workers.reserve(current.format, job.id);
if (!slot) break;

updateJob(job.id, { status: 'reading', format: current.format });
void job.file.arrayBuffer().then((buffer) => {
  slot.post({ type: 'process', jobId: job.id, buffer, /* … */ }, [buffer]);
});

If you mark the worker busy inside the .then(), the loop keeps iterating while every arrayBuffer() is still pending, sees the same idle workers over and over, and over-dispatches the whole queue at once. reserve() flips busy synchronously and returns a handle; the async read then posts through that handle. The pool's own comment says it plainly: "Synchronously reserves a worker (spawning if needed) so async file reads can't over-dispatch."

Note the [buffer] transfer list — the ArrayBuffer moves to the worker rather than being cloned, and the finished encode is transferred back the same way.

AVIF gets a concurrency limit of exactly one

The pool exposes a single boolean for this, and the dispatch loop consults it before every AVIF job:

/** true while any worker is encoding AVIF (max 1 concurrent AVIF job). */
get avifInFlight(): boolean {
  return this.handles.some((h) => h.busy && h.format === 'avif');
}

// AVIF is the heavy codec: never run two at once (memory + heat)
if (current.format === 'avif' && workers.avifInFlight) continue;

continue, not break — a queued AVIF job doesn't stall jobs behind it.

AVIF `speed` is the single highest-leverage parameter

AVIF's speed option (higher = faster encode, lower = smaller file) has a much steeper cost curve single-threaded than the docs' framing prepares you for. Measured on my machine on a 12 MP image: speed: 7 took 143 seconds. speed: 9 came in around 40. Same file, same build.

143 seconds is not a slow tool, it's a broken one — the user has closed the tab. So the encoder is pinned:

case 'avif': {
  // speed 9: measured on 12MP — speed 7 took 140s+ single-threaded,
  // which is unusable; 9 trades a little size for a big time win
  const buffer = await (await import('@jsquash/avif')).encode(imageData, {
    quality,
    speed: 9,
  });
  return { buffer, mime: 'image/avif' };
}

If you benchmark AVIF in a multithreaded Node script and then ship the number to a single-threaded browser build, you will be wrong by an order of magnitude. Measure where it runs.

JPEG has no alpha channel, and mozjpeg won't tell you

Hand a decoded transparent PNG straight to the JPEG encoder and it reads the RGB channels while ignoring alpha — so whatever colour was hiding under alpha = 0 ships in the output, usually black or a bleeding edge colour. No error, no warning. The fix is to composite first, which means owning a blend function:

for (let i = 0; i < src.length; i += 4) {
  const a = src[i + 3];

  if (a === 255) {
    // identity fast path — opaque pixels must survive bit-exact
    out[i] = src[i];
    out[i + 1] = src[i + 1];
    out[i + 2] = src[i + 2];
  } else if (a === 0) {
    out[i] = bgR; out[i + 1] = bgG; out[i + 2] = bgB;
  } else {
    const inv = 255 - a;
    out[i] = Math.round((src[i] * a + bgR * inv) / 255);
    // …g, b
  }

  out[i + 3] = 255;
}

Two details worth stealing. The a === 255 branch isn't only about speed: routing opaque pixels through the multiply-and-round would introduce drift on the pixels that were supposed to be untouched. And keeping this as a pure function over ImageData — no DOM, no worker globals — means it's unit-testable under Node, which is where its five tests run. The one wrinkle is that ImageData doesn't exist there, so construction is guarded:

if (typeof ImageData === 'function') return new ImageData(data, width, height);
return { data, width, height, colorSpace: 'srgb' } as unknown as ImageData;

jSquash only reads data, width and height, so the plain object is enough.

Only the JPEG path flattens. WebP, PNG and AVIF take the ImageData as-is and keep their alpha. The background colour is user-selectable, defaults to white, and parseHexColor falls back to white on anything it can't parse.

Vite pre-bundling breaks WASM asset resolution

This is the one that costs an afternoon if you don't know it, and it's a two-line fix:

vite: {
  optimizeDeps: {
    // jSquash WASM modules must not be pre-bundled (worker + wasm asset resolution)
    exclude: [
      '@jsquash/jpeg', '@jsquash/png', '@jsquash/oxipng',
      '@jsquash/webp', '@jsquash/avif', '@jsquash/resize',
    ],
  },
},

Every jSquash package you use goes in the list, @jsquash/resize included.

Keeping them out of the pre-bundle also preserves lazy loading. Every codec in the worker is imported dynamically at the point of use:

case 'image/webp': return (await import('@jsquash/webp')).decode(buffer);

so a visitor converting JPEG to WebP never downloads the AVIF module at all. The PNG output path chains two of them — encode with @jsquash/png, then run @jsquash/oxipng's optimise() at level 2 — and neither is fetched unless PNG is the chosen output.

What I'd do differently

Decide the isolation question first. COOP/COEP versus ad revenue determines whether you're writing a scheduler at all. Discovering it after building the fast path is the expensive order.
Benchmark in the browser, single-threaded, on a big image, before choosing codec parameters. The AVIF speed number was the difference between a usable tool and an abandoned tab.
Assume every codec fails silently at least once. JPEG's missing alpha, unusual-but-valid files the codecs reject (the compressor falls back to createImageBitmap + OffscreenCanvas for those) — none of it throws. It just looks slightly wrong, and only in the output.
Keep the pixel math out of the worker. Anything expressible as a pure function over ImageData should live in a testable module. That's the only part of this pipeline I could write tests for without a browser.

Parsing Adobe Illustrator .ai files in the browser with pdf.js — four things the docs don't tell you

kyungju lee (Benjie) — Fri, 21 Aug 2026 04:42:22 +0000

An .ai file is not really an Illustrator format. If it was saved with Create PDF Compatible File turned on (the default since Illustrator 9), the bytes on disk are a PDF container — every artboard is a page. That single fact is what makes a browser-side .ai viewer possible at all: you don't need to reverse-engineer a proprietary format, you point pdf.js at it and it opens.

Detection is a byte-signature check on the head of the file, not the extension:

export function detectAiKind(bytes: Uint8Array): AiFileKind {
  const head = new TextDecoder('latin1').decode(bytes.subarray(0, 1024));
  if (head.includes('%PDF-')) return 'pdf';       // modern, PDF-compatible
  if (head.includes('%!PS-Adobe')) return 'postscript'; // Illustrator 8 and older
  return 'unknown';
}

%PDF- is searched for rather than matched at offset 0, because the PDF spec tolerates leading bytes before the header. Illustrator 8 and older wrote PostScript, and no browser will read those — that path gets an honest error message instead of a spinner.

So far, so easy. Everything after that was a series of failures that produced no error message at all. I built ArtboardLab, a free browser-based tool set where nothing gets uploaded, and these four lessons all come from its .ai viewer/converter.

Trap 1: no `cMapUrl` and CJK text silently disappears

The first Korean-language .ai file I tested rendered perfectly — except every single glyph of Korean text was gone. No exception, no console warning, no fallback box. Vector shapes fine, Latin text fine, Hangul just not there.

CID-keyed fonts (Korean, Japanese, Chinese, and other multi-byte encodings) need Adobe's CMap tables to map character codes to glyph IDs. pdf.js ships those tables, but it does not bundle them into the library — it fetches them at runtime from wherever cMapUrl points. If you don't set the option, there's nothing to fetch, and the failure mode is silence.

const task = pdfjs.getDocument({
  data: buffer,
  // CJK (and other CID) fonts need Adobe CMap data — without cMapUrl,
  // Korean/Japanese/Chinese text silently drops every glyph.
  cMapUrl: '/pdf-assets/cmaps/',
  cMapPacked: true,
  // substitutes for non-embedded standard fonts
  standardFontDataUrl: '/pdf-assets/standard_fonts/',
  // JPX (JPEG 2000) image decoding
  wasmUrl: '/pdf-assets/wasm/',
});

Two related options have the same shape of problem. standardFontDataUrl supplies substitutes for the standard fonts a document references but doesn't embed, and wasmUrl points at the WASM used for JPX (JPEG 2000) images, which show up in print-oriented artwork more often than you'd expect.

All three directories are copied into the site's static assets and served from the same origin — 198 files, mostly .bcmap tables, about 3.3 MB. Nothing goes to a CDN. Check that those assets actually shipped: a missing CMap directory doesn't break the page, it just quietly deletes other people's languages.

Trap 2: transparent rendering is broken, so render twice

Exporting a PNG with a transparent background sounds like a one-liner. pdf.js's render() takes a background option, so pass a transparent color and you're done.

It comes out solid black. 'rgba(0,0,0,0)', the string 'transparent', even a transparent CanvasPattern — all of them paint opaque black in pdf.js v6. I verified each variant before accepting the conclusion, because it feels too basic to be broken.

The fix is the classic compositing trick: render the page twice, once on white and once on black, and derive alpha from the difference between the two. A fully opaque pixel looks identical on both backgrounds; a fully transparent one differs by the full range; anything in between lands proportionally in the middle. The black composite is already premultiplied by that alpha, so dividing it back out recovers the color.

const white = await renderToImageData(page, viewport, '#ffffff');
const black = await renderToImageData(page, viewport, '#000000');
const w = white.data;
const b = black.data;

for (let i = 0; i < w.length; i += 4) {
  const diff = (w[i] - b[i] + (w[i+1] - b[i+1]) + (w[i+2] - b[i+2])) / 3;
  const alpha = 255 - Math.max(0, Math.min(255, Math.round(diff)));
  if (alpha === 0) {
    b[i] = b[i+1] = b[i+2] = b[i+3] = 0;
  } else {
    b[i]   = Math.min(255, Math.round((b[i]   * 255) / alpha));
    b[i+1] = Math.min(255, Math.round((b[i+1] * 255) / alpha));
    b[i+2] = Math.min(255, Math.round((b[i+2] * 255) / alpha));
    b[i+3] = alpha;
  }
}

The cost is what it looks like: every transparent render is two renders. Thumbnails and the preview want real alpha too — so the UI checkerboard shows what's actually transparent — which means the doubling applies across the whole pipeline, not just export.

Two practical notes. Read pixels back with getContext('2d', { willReadFrequently: true }) — this is a full-surface getImageData on every render. And zero out canvas.width/canvas.height when done: at export scale these backing stores are enormous. There's also a hard cap of 8192 px on the long edge, with the scale reduced proportionally and a notice shown, rather than letting a huge artboard hit the canvas limit.

Trap 3: SVG export needs an old pdf.js, lazily loaded, with three specific flags

pdf.js used to have an SVG backend, SVGGraphics. It was removed after the 3.x line. If you want an .ai → SVG path that keeps paths as vectors, you either write a PDF-operator-to-SVG converter yourself or you keep an old build around. I kept the old build: pdfjs-legacy is an npm alias for pdfjs-dist@3.11.174, living alongside v6 in the same package.json.

That's a real cost, so it's paid only on demand: the legacy module is imported with await import(...) inside the export handler, never at module scope — its worker file alone is about 1.1 MB minified. It runs as a fully separate instance: its own worker, its own GlobalWorkerOptions, its own document. Nothing is shared with the v6 pipeline.

Three options are not optional on that build, and each fixes a different failure:

const task = legacy.getDocument({
  data: new Uint8Array(await file.arrayBuffer()),
  // 3.11.174 predates the CVE-2024-4367 fix — font programs must never
  // be able to reach eval().
  isEvalSupported: false,
  // without this, pdf.js drops the translated font data and SVGGraphics'
  // embedFonts pass throws `addFontStyle: No font data available`
  fontExtraProperties: true,
  // with OffscreenCanvas the worker returns images as ImageBitmap and leaves
  // imgData.data null; SVGGraphics predates bitmaps and reads .data
  // unconditionally, so any raster image throws `null.subarray`.
  isOffscreenCanvasSupported: false,
  cMapUrl: '/pdf-assets/cmaps/',
  cMapPacked: true,
  standardFontDataUrl: '/pdf-assets/standard_fonts/',
});

isEvalSupported: false — this build predates the fix for CVE-2024-4367, where a crafted font program could reach eval(). Running a stranger's .ai file through a known-vulnerable parser is exactly the scenario the CVE describes, so this one is non-negotiable. (v6 removed the option entirely; font programs can't get to eval there at all.)
fontExtraProperties: true — pdf.js normally discards translated font data once it has rendered with it. SVGGraphics.embedFonts needs that data to write @font-face rules, and without it you get addFontStyle: No font data available.
isOffscreenCanvasSupported: false — when OffscreenCanvas is available, the worker hands images back as ImageBitmap with imgData.data left null. SVGGraphics was written before bitmaps existed and reads .data unconditionally, so any placed raster image throws null.subarray.

Two smaller things in the same file. SVGGraphics is constructed with forceDataSchema = true so fonts and images are inlined as base64 data: URIs — the default blob: URLs die with the page session, which would leave the downloaded .svg full of unresolvable references the moment the user closes the tab. And the 3.x TypeScript types claim getSVG() resolves to void; it actually resolves to the SVG root element, which needs a cast.

One non-obvious detail: the SVG path re-reads the original File from disk instead of reusing the buffer. The ArrayBuffer handed to the v6 worker at open time was transferred, so it's detached. Same for the PDF export path.

Trap 4: two renders on one `PDFPageProxy` produce black output

Opening a file kicks off three things at once: render the preview, build thumbnails for every artboard, and scan the document for warnings. Run them concurrently and output starts coming back all black — not an exception, just wrong pixels, and not reliably reproducible.

render() and getOperatorList() on the same PDFPageProxy don't tolerate overlapping. And note that trap 2 doubled the number of renders per page, which makes the overlap far easier to hit.

The fix is unglamorous: one promise chain that every piece of page work goes through.

let pageWork: Promise<void> = Promise.resolve();

function enqueue(work: () => Promise<void>): Promise<void> {
  pageWork = pageWork.then(work).catch(() => {});
  return pageWork;
}

Two consequences worth stating, since both bit me later:

The .catch(() => {}) is deliberate — one broken page must not poison the chain for everything queued behind it. But that means a caller can't learn about failure from the returned promise, so anything that needs to report an error records it inside its own task and reads it afterwards.

And the SVG export deliberately does not go through this chain. It opens its own document on its own worker, so it shares no PDFPageProxy with the v6 pipeline — and routing it through enqueue would swallow exactly the errors the UI needs to show.

There's also an openToken counter, bumped on every open/reset, checked before each state write. Async work belonging to a file the user already replaced bails out instead of writing stale thumbnails into the new document's UI.

What's still best-effort, honestly

Some of this is solved. Some is as good as it gets in a browser, and the UI says so rather than pretending:

SVG text is outlined, not selectable. Shapes are exact; you can't edit the copy or change the typeface afterwards.
Complex effects can differ. Gradient mesh and blend modes are where SVG output diverges from Illustrator — which is why the preview exists, so you see the divergence before downloading.
Photo-heavy files produce enormous SVGs, since every raster image is inlined as base64. PNG is the right answer for those, and the tool says so.
CMYK is shown as RGB. The document is scanned for CMYK color operators and a notice is shown when it finds them, because print colors will not match on screen.
Non-embedded fonts get substituted. Detecting that relies on a private pdf.js structure (commonObjs._objs), wrapped in a try/catch — if the internal shape changes, the warning is skipped silently rather than breaking the page.
Illustrator 8 and older can't be opened at all, and files saved without PDF compatibility often contain only a placeholder page. Both are detected and explained instead of failing mysteriously.

The general lesson, if there is one: pdf.js's hardest bugs here didn't throw. Missing glyphs, black canvases, and silently corrupted renders all look like a working app until someone opens a file in a language you don't read.