How PDF Text Extraction Runs in Your Browser
A PDF stores text as a stream of low-level operators: Tj and TJ commands that place strings of glyph codes at positions on the page, using fonts whose internal encodings map those codes back to characters. To read them, this page loads PDF.js (pdfjs-dist 3.11.174). The file is read into an ArrayBuffer and handed to getDocument(), which returns a promise for a parsed document; a Web Worker thread — fetched once from a CDN — performs the heavy tokenizing so the UI thread stays responsive.
Extraction then walks every page with getTextContent(). The parser interprets the content stream, decodes each text-showing operator, maps glyph codes to Unicode using each font's encoding table or ToUnicode CMap, and applies the transformation matrices that position glyphs on the page. The result is a flat list of text items — runs of characters with coordinates. Reassembling them into prose is where layout awareness matters: items are concatenated with spaces in the order the content stream defines, and pages are separated by blank lines. Multi-column designs or tables can interleave visually, so output order can differ slightly from the reading order a human would choose.
The assembled string is wrapped in a UTF-8 Blob with the text/plain MIME type and offered for download via an object URL. Nothing about the document — not a page, not a glyph — is ever serialized back to a server. Since the parsing library runs locally, the approach also handles documents that would be too sensitive to upload elsewhere: the whole read-parse-assemble cycle consumes zero bandwidth for your data and leaves no trace once the tab closes.