I do contract work on my own, and the part I never controlled well was the gap between sending a proposal and the client actually reading it. Two failures taught me the same lesson from opposite directions. One client edited two numbers in the Word file I sent, passed it along internally, and the sign-off went by his copy. Another client told me my PDF opened with blurry images on his office machine and asked for something he could just look at.
So I stopped picking a format out of habit. Before I send anything now I ask three things: can they edit it, what do they need installed to open it, and how big is the attachment.
Editability is a versioning question, not a security one. Word is writable by design, which is what you want while the document is still being written together. Sending Word after sign-off means you volunteered to track which copy is authoritative. A PDF raises the bar but does not close the door. The third option is a read-only single-file HTML: they double-click, the browser opens it, they can read, select and copy, and there is no edit mode short of touching the source.
That third option only works if the exported file is genuinely self-contained, so I took an afternoon to take one apart. I built a proposal-style document to test with — seven A4 pages, a 36-row table, three images, four footnotes, a three-level numbered list, headers and footers. The company name, the order numbers and the money in it are all invented. I converted it with ImgIng (https://imging.ai/ ), which runs the conversion locally in the browser. I watched the network panel across six runs: zero non-GET requests during processing, nothing left the machine.
The output is one 85,903-byte HTML file. First thing I checked was external references: zero external scripts, zero external stylesheets, zero remote images. The three pictures are inlined as base64 and account for 31% of the file. I also grepped for unzip libraries, OOXML namespaces and the base64 signature of a zip archive. All zero, so it is not shipping the original package plus a parser.
The check that mattered most to me was the next one. Plenty of "single file" exports stuff the content into a script and render it at runtime, which means a blank page on a locked-down office desktop. I turned JavaScript off completely and reopened the file on the desktop: still seven pages, a line-by-line diff of the body against the scripted version came back with zero differences, and I could select and copy 3,178 characters. Against the source document's 286 body paragraphs, 286 matched.
Then I hit the real limitation. I made a second sample using a font my machine does not have, and embedded a full copy of that font in the document the way Word allows. In the output, the number of embedded font declarations is zero. The font did not travel; only its name did. Same headline, 575.3×81 px with the font installed, 411.9×33 px without, and Chinese body paragraphs differ by 45.6% in height. Page height is baked in at conversion time from the original document and does not recompute, so one page in that sample pushed its content past the page boundary and clipped half a line.
That settles what this format is for: it carries content and structure, not typography. A cover headline leaning on a font will not look like that on their machine.
The deck side is a different trade. Eight slides came out as 202,324 bytes, all 1280×720 with the source ratio preserved, four rotated objects matching their original angles, the table still a real table, SmartArt vector with all five stage labels selectable. The bar chart and the pie chart are frozen into PNGs. Axis labels and data values appear zero times in the file, and only the legend is selectable. Animations and transitions do not run; the number of animation definitions in the output is zero.
Three things I check before sending, all of which burned me once: the footer page numbers (mine printed the same page 1 of 10 on all seven pages), the WordArt title (blank), and the embedded Excel object in the body (gone entirely, preview image included). The tool only shows one merged line saying an embedded object was detected, without naming the page or the object.
On size: both are fine as attachments. Don't subtract those numbers from the source file size, though — .docx and .pptx are zip archives and the output is one uncompressed file, so the ratio tells you nothing.
And one thing I can't answer: I don't have Word installed, so I have no idea how closely this matches what Word would render. All I can say is the seven page breaks line up with the six manual breaks in my document.
Top comments (0)