You open Quarterly-Report.docx in LibreOffice Writer, save it as ODT, and something is subtly off. The document is now 13 pages instead of 12. A heading that sat tight against its paragraph now has a gap. One table column is 4 mm narrower. Nothing is broken — but your Word-using colleague will notice.
This is not a bug you can file. DOCX to ODT conversion is a translation between two different layout models, and a handful of predictable things get lost in translation. Below: what actually shifts, why, and the concrete fixes — including the soffice --convert-to odt command line for batches and an online route when you do not want to install anything.
Why DOCX and ODT never line up perfectly
DOCX (OOXML) and ODT (OpenDocument) both store text, styles and layout as XML inside a ZIP. But they describe the page differently, and the converter has to make judgement calls. Four areas account for almost every complaint.
1. Font substitution — the biggest offender
Word documents routinely use Calibri, Cambria, Segoe UI or Aptos. On Linux and many macOS setups those fonts are simply not installed, so LibreOffice substitutes something metrically different. Carlito and Caladea are open metric-compatible clones of Calibri and Cambria — if they are installed, line breaks land in the same place. If they are not, LibreOffice falls back to Liberation Sans or DejaVu Sans, which are wider, and every paragraph reflows.
Check what happened: Tools › Options › LibreOffice › Fonts shows the replacement table, and Tools › Macros is not needed — simply click into the text and look at the font name box. If it shows the original name but renders differently, you are looking at a substitution.
2. Style inheritance and spacing
Word's "Don't add space between paragraphs of the same style" and contextual spacing have no exact ODT equivalent. Word also collapses the larger of two adjacent spacings in some cases; ODT adds them. Result: extra vertical air after headings and between list items, which is where most of your extra page comes from.
Word themes are another gap. A DOCX heading styled via a theme font (+Headings) resolves to a literal font name on conversion, so later theme edits no longer propagate.
3. Tables
Autofit tables are the trouble spot. Word stores a preferred width plus autofit rules; ODT stores concrete column widths. When a table is set to "autofit to contents", the converter freezes whatever widths were computed at save time — then re-renders with substituted fonts, so the text inside no longer matches the frozen widths. Nested tables, cell margins and "repeat header row" usually survive; vertical text in cells and some border art do not.
4. Numbering and lists
Word keeps a document-wide numbering definition table that paragraphs point into. ODT attaches list styles more directly to paragraphs. Multi-level lists that restart, legal numbering (1.1.1), and lists interrupted by a non-list paragraph are the ones that break — you get a restart at 1 or a wrong indent on level 3. Simple bullets and single-level numbers convert cleanly.
Fix the inputs before you convert
Most shifts are preventable in two minutes. Do this before converting anything important:
- Install the metric-compatible fonts. On Debian/Ubuntu:
sudo apt install fonts-crosextra-carlito fonts-crosextra-caladea. This alone fixes the majority of "wrong formatting when opening a Word file in LibreOffice" reports. - Or embed fonts in the source DOCX. In Word: File › Options › Save › Embed fonts in the file. The DOCX grows (a 180 KB file can become 2–3 MB), but line breaks are reproducible anywhere.
- Turn off autofit on tables in the source, or set fixed column widths in centimetres.
- Flatten exotic numbering — if a multi-level list is decorative rather than legal, a simple list style travels better.
- Check compatibility options in LibreOffice: Tools › Options › Writer › Compatibility, and enable Use Word-compatible trailing blanks and Add spacing between paragraphs and tables to match Word's model more closely.
Converting DOCX to ODT on the command line
LibreOffice ships a headless converter — soffice (or libreoffice) — that is the fastest route for more than one file. Close all LibreOffice windows first; headless mode refuses to run alongside an open GUI profile.
Single file:
soffice --headless --convert-to odt Quarterly-Report.docx --outdir ./odt/A whole folder of Word files:
soffice --headless --convert-to odt --outdir ./odt/ ./word-source/*.docxLegacy .doc works the same way (--convert-to odt *.doc), and this is also the cleanest answer to doc to odt formatting complaints: the binary .doc filter is mature and usually loses less than people expect.
Two practical notes. First, paths: on Windows the binary lives at C:\Program Files\LibreOffice\program\soffice.exe; on macOS at /Applications/LibreOffice.app/Contents/MacOS/soffice. Second, use a throwaway profile so your personal settings (and any open session) stay out of the way:
soffice --headless -env:UserInstallation=file:///tmp/lo-convert \
--convert-to odt --outdir ./odt/ report.docxExpect size to drop: a 480 KB DOCX with three embedded PNGs typically lands around 430 KB as ODT, because the ZIP contents differ slightly. A much smaller output file is a warning sign — images may have been dropped.
The no-install route
If you are on a locked-down machine, converting one file for a colleague, or working from a tablet, installing an office suite to change a file extension is overkill. Our browser-based DOCX to ODT converter takes the file, returns a standards-clean ODT and skips the setup entirely — useful when you just need contract-v3.docx as ODT before a meeting.
If the rest of the project involves PDFs, RTF or spreadsheets too, the wider document converter hub covers the same ground for other formats.
Whichever route you take, do the same 60-second check afterwards.
The 60-second post-conversion check
- Page count. Compare with the original. A difference of one page almost always means font substitution or paragraph spacing.
- Last line of the document. If it moved to a new page, something above it grew.
- Widest table. Does any column now wrap where it did not before?
- Level-3 list items. Check numbering continuity and indent.
- Headers, footers and page numbers. Section-specific headers are the most fragile part of multi-section documents.
- Images and text wrap. Anchored-to-character images shift most often; re-anchor to paragraph if one jumps.
When to stop fighting and keep DOCX
Round-tripping — DOCX → ODT → DOCX → ODT — compounds every small shift. If a document is actively co-edited with Word users, pick one format and stay there. LibreOffice edits DOCX natively and well; you are allowed to use it. Reserve ODT for documents you own: templates, archives, internal docs, anything you want readable in 15 years without a proprietary spec.
A workable rule: convert to ODT at the end of a document's life, not in the middle of it. Do the collaboration in DOCX, archive the final in ODT, and the layout shifts stop being a daily annoyance.
FAQ
Does converting DOCX to ODT lose content? Text, headings, tables, footnotes, comments and tracked changes survive. What degrades is presentation: fonts, exact spacing, autofit tables, complex numbering, SmartArt (converted to images) and some field codes.
Why does my document gain a page in LibreOffice? Almost always font substitution. Install Carlito and Caladea, reopen the file, and the page count usually matches again.
Can I convert ODT back to DOCX? Yes: soffice --headless --convert-to docx file.odt. Avoid repeat round trips, as spacing drift accumulates.
Will Microsoft Word open an ODT file? Yes — Word has read and written ODF for years. Expect the same class of minor layout differences in the other direction.
Is `--convert-to odt` the same quality as File › Save As? Yes, it uses the identical export filter. The only difference is that headless mode makes no interactive decisions, so it never prompts about keeping the Word format.
What about old `.doc` files? The same command handles them. Legacy binary .doc converts to ODT reliably; the usual casualties are WordArt, old drawing objects and macros.
