Spent last week debugging why a pitch deck came back from my PPTX-to-Markdown converter with the appendix before the actual pitch. Turned out the slide files inside the .pptx package are named slide1.xml , slide2.xml , slide3.xml — but that numbering has nothing to do with presentation order. The real order lives in presentation.xml as a list of relationship IDs pointing at slide files in whatever sequence the author dragged them around in PowerPoint. So a deck saved after someone moved the "Thank you" slide to the front, then back to the end, has slide7.xml as the first slide and slide1.xml somewhere in the middle. My converter was reading files alphabetically and happily handing agents a pitch deck that starts with Q&A and ends with the company logo. The fix was parsing p:presentation/sldIdLst and resolving each r:id through presentation.xml.rels to the actual target file. Boring XML plumbing, but it's the difference between "Markdown of a deck" ...

The idea behind the universal converter was simple: hand it any document, it figures out the type, converts to Markdown. No routing on the caller's side. One endpoint. The failure mode I didn't plan for: a PDF that arrives named report.docx . A user sent a contract scanned to PDF, but their pipeline renamed it with a .docx extension because "that's what the upload widget defaults to." My sniffing logic checked the extension first, trusted it, fed the bytes to the DOCX parser, and got back a Markdown file containing the raw binary noise of a PDF header. Not an error — worse, plausible-looking garbage. The fix was to stop trusting filenames entirely. Now the converter sniffs magic bytes: %PDF- for PDF, the PK\x03\x04 zip signature for OOXML formats (then peeks inside the zip for word/ , xl/ , ppt/ to distinguish DOCX/XLSX/PPTX), ID3 or \xFF\xFB for MP3, and so on. Extension is only a tiebreaker when magic bytes are ambiguous — which, for the formats I supp...

When my PDF, DOCX, XLSX, PPTX and EPUB converters ran as separate endpoints, agents kept picking the wrong one. A universal "send anything, we'll figure out the type" endpoint was the obvious fix. My first detection logic: file extension first, Content-Type header as backup. It survived about a day of real traffic. The file that broke it: a contract named invoice.pdf. My PDF parser opened it and found no %PDF header at all — it was a DOCX somebody had renamed during a mail-merge export. And I couldn't lean on names even in general, because a large share of my uploads arrive as raw base64 with no filename, and most clients stamp anything ambiguous as application/octet-stream. Extensions and headers are rumors. Bytes are facts. So I rebuilt detection from the bytes up: Starts with %PDF- — easy, it's a PDF. Starts with PK — it's a zip container, unzip and peek inside. A word/document.xml means DOCX, xl/workbook.xml means XLSX, ppt/presentation.xml means ...

I built a universal document converter whose whole pitch is "give it any file, it picks the right parser." Auto-detection turned out to be the hardest part of the product. The failure: a pipeline I operate ingested a batch of "PDFs," and one blew up with a zip-related error deep inside the PDF parser. I opened the file — it was a Word document someone had renamed to .pdf before emailing it. Every human tool opened it fine, because Word doesn't care what the extension says. It sniffs the bytes. So I stopped trusting extensions. Then I stopped trusting Content-Type headers too, because I immediately found a server labeling real PDFs as application/octet-stream and another serving a DOCX as application/pdf . Headers are configured by humans; bytes are configured by whatever created the file. Magic bytes got me most of the way: real PDFs start with %PDF- , and the whole Office family starts with PK — they're ZIP archives. But that's where the trap was: ...

When I added auto-detect to my universal document converter, I assumed file extensions and Content-Type headers would carry the weight. Both lied to me within the first week. A contract arrived named contract.pdf . The extension said PDF, the upstream header said application/pdf. My PDF parser choked on byte zero: the file was actually a DOCX. Someone had renamed an export, and a proxy in the delivery chain had stamped the header based on the filename. Nothing on the outside matched what was inside. Magic bytes seemed like the obvious fix, and PDFs declare %PDF , so that part worked immediately. Then an uncomfortable fact surfaced: DOCX, PPTX, XLSX, and EPUB are all ZIP archives. They share the exact same PK\x03\x04 signature — one magic number, four formats. The disambiguation lives inside the container: EPUB is required to store a file literally named mimetype as the first entry, uncompressed, containing application/epub+zip . Two reads and you're done. Office formats carr...