Keep Writer Revisions Visible When Exporting to DOCX

To send a reviewable DOCX from LibreOffice Writer, save a working copy as ODT, turn on Track Changes > Record, make sure Show is on, and use File > Save As to create a separate Word DOCX file. Then open that DOCX in the version of Microsoft Word your recipient uses and check it with Review > All Markup. This preserves an editable source and catches conversion problems before you share the file, but no export setting can guarantee identical formatting in every document.

The controls below reflect the LibreOffice 26.8 Help documentation checked October 9, 2026. Menu placement can vary by operating system, interface mode, and release; if a label differs, use the equivalent command in the Edit or Review interface.

What do Record and Show actually do?

Record tells Writer to capture new edits, including who made them and when. Show controls whether tracked changes are visible in the document. Hiding changes does not delete them, and turning recording off does not accept or remove changes already stored in the file. These are separate controls, so check both before editing and exporting.

In the standard menu, choose Edit > Track Changes > Record. In tabbed mode, the corresponding control is on the Review tab. To display existing marks, choose Edit > Track Changes > Show. The Track Changes toolbar also separates the Record and Show controls. See the LibreOffice instructions for recording changes and the Track Changes toolbar reference.

LibreOffice Writer Edit menu with Track Changes expanded and Record and Show checked
Enable Record to capture edits and Show to see the tracked marks while you work.

How should you prepare the document?

  1. Keep an untouched source. Open the document and save a working copy in OpenDocument Text format (.odt), using a new filename. If the file already came from Word, preserve the original DOCX as well. This gives you a version to return to if the exported file changes line breaks, spacing, or object placement.
  2. Start recording before editing. In Writer, select Edit > Track Changes > Record, or use Review > Record in the tabbed interface. Check that the command is enabled. For a clear test within your actual document, add a short phrase and delete a different phrase; do not rely on color alone as proof that tracking is active.
  3. Make the marks visible. Turn on Edit > Track Changes > Show. Writer displays insertions and deletions as revision marks, with change indicators in the page margin. The exact colors and markup presentation can depend on settings, so look for the change itself and its author or revision controls, not a particular color.
Writer page showing an underlined insertion, a struck-through deletion, and change bars in the margin
An insertion and deletion remain visible as separate revisions, with change bars beside the edited lines.

For example, if a sentence says “The review starts Monday” and you change it to “The review starts Tuesday,” the recipient should be able to inspect the removed word and the replacement separately. If the sentence simply appears as “Tuesday” with no revision mark, pause and confirm that Record was on while editing. A visible difference in the final text by itself is not proof of an editable tracked change.

How do you export without discarding the review markup?

  1. Save the ODT working copy. Leave the changes unresolved if the recipient needs to accept or reject them.
  2. Choose File > Save As, enter a distinct name such as proposal-review.docx, and select Word 2010–365 Document (.docx) as the file type. LibreOffice’s current filter list uses this name for its DOCX export filter. The Save As dialog may ask you to confirm the chosen format; select the option to use the Word format for this copy.
  3. Keep the ODT file. Do not replace your only source with the DOCX. If you accepted/rejected revisions or switched to a view that hides markup, those actions do not serve as an export-quality check. Save a separate review copy instead.

LibreOffice documents that it can load and save Microsoft Office formats, while also warning that complex layout and formatting may be handled differently or unsupported. It specifically lists revision marks as one of the possible conversion challenges. That is why “Save As DOCX” is a format conversion, not a promise of pixel-for-pixel or feature-for-feature equivalence. Review the LibreOffice guide to saving in Microsoft Office formats, its document filter list, and its notes on Microsoft Office import and export limitations.

LibreOffice Save As dialog with proposal-review.docx and Word 2010–365 Document selected
Choose the DOCX filter and a new filename so the ODT working source remains available.

What should you check in Microsoft Word?

Open the exported file in Word, not only back in Writer, if Word is the recipient’s target application. On the Review tab, select All Markup so insertions, deletions, and other supported revisions are displayed. Microsoft explains that a view such as No Markup can hide changes without removing them; accepting or rejecting changes is the action that removes them from the document. See Microsoft’s Track Changes guidance for Word.

Check one insertion and one deletion, then scan the parts of the document most likely to shift: headings, tables, numbered lists, images, page breaks, headers, footers, and section boundaries. A short text-only memo may need only a quick pass. A long report with columns, complex tables, anchored images, or many sections deserves a page-by-page comparison because these structures make conversion differences more consequential. This is a risk-based check, not a guarantee that every possible feature has been tested.

Microsoft Word Review tab with All Markup selected and tracked insertions and deletions visible
Use All Markup in Word to confirm the exported file still contains visible, reviewable revisions.

When should you change the workflow?

If Word shows no marks, first confirm that you opened the intended DOCX and that All Markup is selected. If the marks still do not appear, return to the ODT source, verify Record and Show, and export a fresh copy. Do not accept every change just to make the file look clean if the reviewer is expected to decide which edits to keep.

If the review marks survive but layout changes matter, use Word for the final formatting pass when Word is the required delivery environment, then save a new DOCX and recheck the revisions. For documents whose appearance must remain fixed, a PDF can accompany the editable DOCX, but it does not replace the reviewable file. The suitable workflow depends on the document’s complexity and the recipient’s software; simple text is generally easier to compare than a document built around elaborate page layout.

How can you confirm the handoff worked?

The DOCX is ready when it opens in Word, All Markup reveals the expected edits, individual changes can be reviewed, and the important page elements remain in place. Keep the ODT source and the exported DOCX together until the recipient confirms the file is usable. If either the revision marks or a critical layout element is missing, treat that as a conversion issue and revise the DOCX in the target application before sending it.

Leave a Comment

Keep Writer Revisions Visible When Exporting to DOCX

Keep Writer Revisions Visible When Exporting to DOCX

Track edits in Writer, preserve an editable ODT source, and check the exported DOCX in Word before sharing it.

Enable FIPS Mode on SLES 15 and Verify the Boot State

Enable FIPS Mode on SLES 15 and Verify the Boot State

Follow SUSE’s SP7 procedure to enable FIPS mode, reboot safely, verify the active policy, and check whether your compliance requirement calls for validated modules.

Set Up a LUKS-Encrypted Data Volume on SLES

Set Up a LUKS-Encrypted Data Volume on SLES

Compare YaST and cryptsetup for a new encrypted SLES data volume, choose LUKS1 or LUKS2, and verify unlock and mount behavior safely.

Build a Custom AppArmor Profile on SUSE Linux

Build a Custom AppArmor Profile on SUSE Linux

Create, refine, and verify a least-privilege AppArmor profile on SLES 15 SP7, with a clear note on SLES 16’s SELinux default.

Build a Local SUSE Update Server with RMT on SLES 15

Build a Local SUSE Update Server with RMT on SLES 15

Set up RMT on SLES 15, mirror entitled repositories, and verify HTTPS registration and package access from a test client.

Join SLES 15 to Active Directory with SSSD in YaST

Join SLES 15 to Active Directory with SSSD in YaST

Connect SLES 15 to AD with YaST’s SSSD-based logon management, then verify directory lookup, domain login, and Kerberos tickets.

Enable SLES Live Patching and Verify a Kernel Fix

Enable SLES Live Patching and Verify a Kernel Fix

Set up the right Live Patching path for SLES 16.0 or 15 SP7, apply eligible kernel fixes, and confirm what is active without confusing it with a reboot-required kernel update.

Install and Sign Custom Kernel Modules on SLES 15 Secure Boot

Install and Sign Custom Kernel Modules on SLES 15 Secure Boot

Load a custom SLES 15 kernel module without disabling Secure Boot. Match the running kernel, sign the .ko file, enroll a MOK key, and verify loading.

Keep Services Available During a SLES 15 SP5 to SP6 Upgrade

Keep Services Available During a SLES 15 SP5 to SP6 Upgrade

SLES 15 SP5 can migrate online to SP6, but each node must reboot. Use a tested rolling upgrade or blue-green cutover to keep workloads reachable.

Apply the SLES 15 STIG Safely with OpenSCAP

Apply the SLES 15 STIG Safely with OpenSCAP

Use SUSE’s supported STIG profile to scan SLES 15, test remediation, review remaining findings, and retain assessment evidence.