The first time I converted a Word doc with formulas and a macro to a webpage to send it, it flopped: the formulas became blurry images, the macro did nothing when clicked, the auto-updating numbering froze. I blamed the converter — until I'd done enough of these to realise these things just don't convert, and it's not the tool's fault. They're the "live" parts of a document, dependent on the Office runtime to work, and a webpage is static; it can't provide that runtime.
Listing what drops, so you can eyeball a doc before converting and dodge most of the pain.
Macros never carry over. Whether to web or PDF, macros aren't executed and aren't copied into the output — which is actually good, a document that auto-runs code is a security liability, and static conversion removes that risk. But if your doc generates content or drives interaction via macros, the converted result is an empty shell.
The runtime-dependent batch survives only as static previews. OLE objects (an Excel table embedded in Word, other apps' embedded content), ActiveX controls, dynamic fields (auto-updating dates, page-reference numbers, caption numbering), complex WordArt, formulas, and some floating drawings — these typically keep only a static snapshot, no longer "live". Dynamic fields especially trip people up: you assume the numbering auto-updates, and after conversion it's frozen at the value it had the moment you converted.
On the PPT side, animations and interactions don't reproduce at all. PPTX-to-web does a read-only static layout: every slide's text, images, tables and positions are there, but animation timelines, transitions, 3D models, embedded DRM media and interactive controls are none of them restored; macros likewise don't run, OLE isn't copied. So a deck that tells its story through animation and interaction converts to a skeleton — layout right, but the "only-meaningful-when-moving" parts gone.
Why exactly these? The rule is clean: anything that needs an engine running live at open-time, static web can't provide. Macros need a macro engine, animations a playback engine, dynamic fields Office's computation, OLE its host app. A webpage just freezes "how it looked at one moment" for you to view — it doesn't ship those engines, so it can't reproduce engine-dependent things. ImgIng's docx/pptx-to-html is honest about this — it renders what can be statically faithful (body, styles, tables, images, layout) and clearly marks the rest as static-preview-only in the workbench, rather than pretending the conversion succeeded.
So before converting, spend ten seconds scanning the doc: any macros, any auto-updating fields, any embedded objects from other apps, does the PPT lean on animation and interaction? Yes — then the web version is a "reading snapshot" only, and the live parts need the original. No — it's plain text, tables, images, static layout, and conversion is near-lossless, send it with confidence. Knowing what drops is how you avoid discovering the gap the moment the client opens it. Tool is ImgIng (imging.ai).
Top comments (0)