Cropping a picture in Word feels final. You drag the black handles, the part you don't want disappears, and you save. But Microsoft's own support page on shrinking picture file sizes offers an option called "Delete cropped areas of pictures", and that option only makes sense if the cropped part is still sitting in the file. In OOXML terms a document can keep the whole image and add three small settings next to it: crop percentages for each edge (a:srcRect), the display size (wp:extent) and a rotation (a:xfrm rot). Any converter that turns the DOCX into a web page has to read those settings back. I wanted to know which ones actually do, since docs full of trimmed screenshots are exactly what people ask me to turn into pages.
One honest caveat first. I don't have Word on this Mac, so my test file is not a Word export. I wrote the DOCX by hand following the OOXML structure, with seven image cases: plain scaling, an uneven crop on all four sides, a 15° rotation, a screenshot with its bottom cut off, a squashed resize, a crop plus a 90° rotation, and an even 15% crop on every side. The screenshot comes from a fake order admin page I built myself, so the recipient, phone number, address and payment ID under "Shipping info" are placeholders. The photo is a landscape from Wikimedia Commons by Dietmar Rabich, CC BY-SA 4.0.
I ran the same file through mammoth.js 1.13.0, docx-preview 0.4.1, the macOS Quick Look thumbnail and macOS textutil. For a browser tool I used ImgIng's DOCX to HTML (imging.ai) on the same 7-case sample in a Chromium 149 open-source build, going through the site's Chinese-language deployment. Here is what each one did.
| Converter | Crop | Scale | Rotation | Cropped part still in the output |
|---|---|---|---|---|
| mammoth.js 1.13.0 | Ignored, whole image shown | Ignored, fills the container | Ignored | Yes, all 7 images are full originals |
| docx-preview 0.4.1 | Right content, drifts off its frame on uneven crops | Correct | Right direction, no space reserved | Yes, behind blob: URLs |
| ImgIng export | Right content, same drift | Correct | Same as docx-preview | Yes, 7 data URIs byte-identical to the originals |
| Quick Look thumbnail | Ignored, whole image squeezed into the frame | Correct | Correct | Not applicable, it's a bitmap |
| textutil | All 7 images dropped | n/a | n/a | No images at all (1,380 bytes of HTML) |
mammoth was the rough one. It skips the crop completely, so the shipping block I had trimmed off the screenshot shows up right there on the page. The red box is mine.
docx-preview gets the visible content right, which is why its failure took me a minute to spot. Going by the inline styles it writes, it clips the image to the crop area and then scales it up from the element's center. When an edge pair is cut unevenly, the picture drifts. The four-side case slid right and up. The screenshot with only its bottom cut moved up 69.7 px and covered the heading above it, leaving just "Scree" visible. The even 15% crop didn't move at all.
ImgIng landed in the same spot, and I'd rather say that plainly than dress it up. It read the crop content and the display size correctly, and the conversion made 0 non-GET requests. Still, the four-side case drifted by (58, −19) px and the bottom-cut screenshot went up 70.4 px over its heading. The UI gave no warning about crops or rotation either. The bigger catch is in the exported file. It is 9,665,338 bytes, and all seven inline images are the untouched originals. Decode the screenshot and you get the full 1800×1240 PNG with the placeholder phone number and address intact. Hidden on screen is not the same as removed.
What fixed it was baking the crop before converting. A small script cut each media file to its srcRect and then cleared the setting. The DOCX shrank 21.0%, ImgIng's offsets went to (0, 0) and (0, −0.4), and the cropped area could no longer be found in any of the three outputs. In Word itself the equivalent should be that "Delete cropped areas" option, but I haven't tried it without a copy of Word. Pure CSS can only hide the cut part. The bytes still ship with the page.
I didn't test Word, WPS, LibreOffice or pandoc, I only checked ImgIng's export in Chromium 149, and floating images weren't part of the sample. If your docs have cropped screenshots, rename a copy to .zip and open word/media. Full-size originals in there mean the crop never happened, so bake it or retake the screenshot before converting, then look at the line right above any bottom-cropped image.
Top comments (0)