Working with documents: PDF, DOCX, and spreadsheets

Document formats are the messiest category, because each was designed around a different idea of what a document is. PDF describes a fixed printed page. DOCX describes a flowing edited manuscript. XLSX describes a calculation model. Converting between them means translating between incompatible mental models, not just re-encoding bytes.

PDF describes a page, not a document

A PDF is a set of drawing instructions: place this glyph from this embedded font at these coordinates on a page of this size. That is the entire model. It is why a PDF looks identical everywhere, and why extracting meaning from one is so much harder than it looks.

A PDF does not inherently know it has paragraphs. Text that appears as a flowing paragraph is a sequence of positioned glyph runs, and reconstructing reading order requires inference about coordinates. This is why copying text out of a two-column PDF so often interleaves the columns, and why extracting a table frequently produces gibberish: the visual grid is drawn lines and positioned text, with no structural relationship between them.

Well-produced PDFs can carry a structure tree describing headings, lists, and tables, which is what makes a PDF accessible to a screen reader. Most PDFs in the wild do not have one.

DOCX and XLSX are ZIP archives full of XML

Both are Office Open XML packages. Rename a .docx to .zip and open it, and you will find the document text in XML, the styles in a separate part, images as ordinary files in a media folder, and a relationships file wiring them together.

The practical consequence is that these formats are genuinely structured. A DOCX records that a paragraph uses the Heading 1 style, which is semantic information that survives conversion. That is why DOCX to HTML can produce real heading elements while PDF to HTML generally cannot.

The catch is that this only works when the author used the structure. A heading created by manually enlarging and bolding a paragraph is, as far as the file is concerned, body text that happens to be large and bold. No converter can recover intent that was never recorded, and the same documents that convert badly are the ones that are inaccessible to screen readers, for exactly the same reason.

Spreadsheets are programs, and CSV is a screenshot

An XLSX file holds a calculation model: formulas, dependencies between cells, named ranges, validation rules, and formatting that often carries meaning. CSV holds the values those formulas last produced.

Exporting to CSV therefore freezes the model. The formula that computed a total becomes the number it produced, and it will not update. Re-importing gives you a grid of constants that looks like the original and behaves nothing like it.

Import is the more damaging direction. Spreadsheet applications aggressively guess types on import, and their guesses destroy data: leading zeros stripped from identifiers, values like 3-4 converted to dates, long numbers rendered in scientific notation. The gene-naming case is the well-known example, where a research convention had to be changed because spreadsheet software kept converting gene symbols into dates. Use the text import wizard and set columns explicitly rather than double-clicking the file.

Why document tools usually want an upload, and why that matters

Historically, manipulating these formats required server-side libraries, so every free PDF merger on the web worked by uploading your file. That is a genuine privacy problem, because the documents people most often need to merge, split, or convert are exactly the sensitive ones: contracts, medical records, tax filings, signed agreements, identity documents.

Uploading such a file means trusting a third party with its contents, its retention policy, and its breach history. Many such services state that files are deleted after an hour, which is a promise rather than a guarantee, and says nothing about what happened in between.

That constraint no longer applies. JavaScript PDF libraries, WebAssembly builds of document toolchains, and the browser own compression and crypto APIs make it possible to do this work in the page. Every tool in this section runs that way, which means the question of retention policy does not arise.

Which conversions are safe

Some directions preserve everything that matters and some are one-way.

• Merging and splitting PDFs is structurally safe. Pages are copied rather than re-rendered, so text stays selectable and quality is unchanged. Document-level features such as bookmarks and form state do not survive.
• PDF to image is lossy in a specific way: it discards the text layer permanently. Useful for thumbnails and previews, wrong as an archival step.
• DOCX to HTML preserves structure well when the source used real styles, and poorly when it did not.
• XLSX to CSV keeps values and discards everything else: formulas, formatting, additional sheets, validation.
• Images to PDF is safe but produces a document with no text layer, which is not searchable and not accessible without a subsequent OCR pass.

Frequently asked questions

Tools referenced in this guide