## Opening a comparison between document versions
In Atloria, start from the document you want to review rather than from the broader project list. Open the page from your content library, project documentation area, or the editor where you were already working on updates. If you need help getting back to a page and its editing workspace, use [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality) as references.

1. Open the document page you want to check.
2. Look for the **Version history** area or the review toolbar that lets you work with saved document states.
3. Choose the two versions you want to compare. A common choice is the **current draft** and the **last published** version, but you can also compare a reviewed version against an approved version if that matches your workflow.
4. Click **Compare** to open the comparison view.
5. Before you begin reading changes, confirm which version is shown as the original and which version is shown as the updated revision.

That last check matters more than it seems. If you reverse the selection, the same edits can look misleading because additions and removals will appear to be swapped. When you are preparing a release update, the safest baseline is usually the currently published page. When you are checking whether review feedback was applied, the baseline is often the earlier reviewed draft.

[SCREENSHOT: Version history panel with two document versions selected and the Compare action highlighted]

If Atloria shows labels for document status, use those labels to pick the right pair. Comparing **Draft** to **Published** helps you see reader-facing changes. Comparing **Reviewed** to **Approved** helps you focus on final editorial adjustments. Choose the pair that matches the decision you need to make.

## Reading additions, deletions, and modified content in the comparison view
Once the comparison view opens, read it as a map of what changed between two saved document states. Atloria highlights inserted text, removed text, and rewritten content so you can quickly spot where the page changed without rereading every line from top to bottom.

1. Start by scanning the page for visual change markers that show edited areas.
2. Open each changed section and review the highlighted wording.
3. Switch between **side-by-side** and **inline** layouts if one view makes the edits easier to understand.
4. Check section headings and content blocks one by one so you do not miss small but important updates.
5. Review any separate metadata changes, such as a changed title or status, apart from the body text.

The **side-by-side** layout is useful when you want to compare full paragraphs, headings, or ordered steps in their original and updated form. The **inline** layout is better when you want to read the page as one continuous flow and see exactly where words were inserted or removed.

Pay attention to section-level indicators. These help you find which heading, paragraph, or content block contains edits before you read the details. On a long page, this saves time because you can jump directly to changed areas instead of manually checking every section.

If the page title, publishing status, or other document details changed, Atloria may show those changes separately from the main body content. Treat those as part of the review. A page can look correct in the body while still carrying the wrong title or status.

[SCREENSHOT: Comparison view showing highlighted additions, deletions, and a layout toggle between side-by-side and inline]

When a paragraph appears heavily changed, slow down and compare meaning, not just wording. A small phrase change in a procedure step or warning note can affect how readers follow the page.

## Reviewing changes before editing or approving updates
The comparison view is especially useful before you reopen a page in edit mode or mark work as ready for review. Instead of guessing whether a requested change was applied, you can verify it directly against the earlier version and confirm that the page still reads consistently from start to finish.

1. Open the comparison for the draft you plan to review.
2. Move through changed sections in order, starting at the top of the page.
3. Check that requested wording updates, terminology fixes, and link changes appear where expected.
4. Confirm that formatting still supports the content clearly, especially in headings, lists, and step-by-step instructions.
5. If your team uses review notes, comments, or approval steps, record your decision before leaving the comparison view.

This step is helpful after a teammate updates a page based on feedback. Compare the current draft against the earlier reviewed or approved state and verify that each requested edit is visible in the changed sections. If a heading was renamed, make sure the wording also matches the body text below it. If a procedure was rewritten, check that the numbered steps still follow the same task flow and that no step was accidentally dropped.

Use comparisons to support editorial review, not just final approval. For example, if a page was updated to align with a new product release, compare the draft against the approved or published version and read only the changed sections first. That keeps your review focused and reduces the chance of overlooking a meaningful update hidden inside a long page.

If your workflow includes sign-off, add comments or review notes directly where your team expects them. Keep those notes tied to specific changes, such as a revised heading, a corrected instruction, or a screenshot update, so the next reviewer can act on them quickly.

## Using comparisons to prepare releases and publication updates
When a document is close to publication, comparisons help you answer one practical question: what will readers actually see change when this version goes live? In Atloria, this is easiest when you compare the release candidate against the currently published page.

1. Open the version you plan to publish.
2. Compare it against the current **Published** version.
3. Review all changed sections with extra attention on headings, procedures, screenshots, and reader-facing labels.
4. Use the results to support release notes, stakeholder review, or final publication approval.
5. Confirm that the comparison contains only intended changes before moving the version to a released or published state.

This review is most valuable for high-impact edits. Rewritten procedures can change how customers complete tasks. Updated screenshots can affect whether instructions still match the screen. Changed headings can alter navigation and make familiar pages harder to find. By comparing the release candidate to the live version, you isolate exactly what is new.

[SCREENSHOT: Document comparison between a publish-ready version and the currently published version]

A comparison can also support conversations outside the editor. If stakeholders want to know what changed since the last release, the comparison view gives you a focused list of edits without requiring a full page walkthrough. It is also useful when preparing release notes because you can quickly identify renamed sections, added steps, and removed guidance.

Before you publish, make one final pass for accidental edits. These often include wording changes in unrelated sections, heading adjustments that were never intended for release, or screenshot replacements that belong to a later update. If the comparison shows more than the planned release scope, return to the draft, clean it up, and compare again.

## Getting reliable results from document comparisons
A useful comparison starts with choosing the right versions. In Atloria, the clearest results come from comparing document states that represent real workflow milestones rather than random saved drafts. That makes the difference view easier to read and easier for reviewers to discuss.

- Compare versions with clear status meaning, such as **Draft**, **Reviewed**, **Approved**, and **Published**.
- Use the same baseline version across reviewers so everyone is discussing the same set of changes.
- Review long documents section by section instead of trying to judge the whole page in one pass.
- Separate formatting-only edits from content edits when both appear in the same comparison.
- Re-run the comparison after major revisions so your review always reflects the latest saved state.

If a page is large, do not try to absorb every change at once. Start with top-level headings, then move through each changed section in order. This is especially helpful for procedure pages, release notes, and long onboarding guides where a small wording change can affect several later steps.

Formatting changes can also make a comparison feel busier than it really is. If Atloria highlights both wording and layout updates, first confirm whether the content meaning changed. Then review formatting changes on their own. This keeps cosmetic edits from distracting you during quality checks.

A shared baseline is important when several people are reviewing the same page. If one reviewer compares the current draft to the published page and another compares it to an older reviewed draft, they may report different findings even though they are looking at the same document. Agree on the baseline first, then compare.

For broader version planning and release-stage comparison work, [Managing Version Lists Statuses and Comparisons](doc:managing-version-lists-statuses-and-comparisons) and [Working with Version Comparison Views](doc:working-with-version-comparison-views) provide the larger workflow around document-level checks.

## Fixing common problems when differences are hard to review
When a comparison feels confusing, the issue is usually the version pair, the layout, or the saved state of the draft. In Atloria, you can usually fix the problem without leaving the document workflow.

- If too many changes appear, return to **Version history** and confirm you selected the correct two versions.
- If the page looks noisy because of formatting updates, switch between **inline** and **side-by-side** views.
- If expected edits do not appear, make sure the latest draft was saved before you opened the comparison.
- If reviewers disagree about what changed, have everyone compare the same baseline and updated version.
- If a long page is difficult to read, review one changed heading or section at a time instead of scrolling through the entire comparison.

A common mistake is comparing the current draft to the wrong earlier draft instead of the last approved or published version. That can make the page look far more changed than it really is. Go back to the version list, check the status labels, and choose the pair that matches your review goal.

Another issue is formatting noise. A rewritten list, adjusted spacing, or heading restructure can make the comparison look dramatic even when the actual instructions barely changed. In that case, switch layouts and reread the affected section for meaning rather than visual density.

If a teammate says a change is missing, confirm that the draft was saved into version history before the comparison was opened. Unsaved edits or edits made in a different draft state will not appear in the difference view you are reviewing.

[SCREENSHOT: Comparison screen with layout toggle and version selectors visible for troubleshooting]

When confusion continues, restart the comparison from the same two named versions for everyone involved. That shared reset usually clears up disagreements quickly.

## Overview
Document comparisons in Atloria help you review what changed between two saved states of the same page. Instead of scanning an entire document manually, you can open a comparison and focus only on the sections that were added, removed, or revised. This is useful during routine editing, editorial review, release preparation, and final publication checks.

You will typically use comparisons in a few common situations:

- Checking a **Draft** against the last **Published** version to see what readers will notice.
- Reviewing a revised draft against an earlier reviewed state to confirm feedback was applied.
- Comparing a release-ready page to the current live page before publishing.
- Verifying that only intended changes are included in a final approval pass.

Atloria’s comparison view supports this work by showing changed sections visually and letting you review updates in either **side-by-side** or **inline** format. That makes it easier to spot rewritten procedures, renamed headings, removed instructions, and updated screenshots without losing track of the original wording.

This guide focuses on document-level comparisons during content updates. It does not repeat the full editing workflow or team review process already covered in [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages), [Organizing and Reviewing Document Content](doc:organizing-and-reviewing-document-content), and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality). Here, the goal is narrower: helping you use comparison views to make better editing and release decisions.

If you regularly update customer-facing documentation, comparisons become one of the fastest ways to catch unintended edits before they reach readers. They also give reviewers a shared view of what changed, which makes approval discussions much more precise.

## Prerequisites
Before you start comparing document versions in Atloria, make sure you have access to the page and that the document already has at least two saved states worth comparing. Comparisons are most useful when the page has moved through clear workflow points, such as draft, reviewed, approved, or published.

- You can open the relevant project and navigate to the document you want to review.
- The document has more than one saved version or status state in **Version history**.
- You know which comparison you need, such as **current draft vs published** or **reviewed vs approved**.
- The latest edits have been saved before you launch the comparison.
- If your team uses review or approval steps, you know whether you are checking changes for editing, review, or publication readiness.

It also helps to be familiar with the document itself before opening the comparison. If you already know the page structure, section headings, and recent requested edits, you can review differences much faster and tell whether a change is meaningful or just cosmetic.

For team-based review, agree in advance on the baseline version everyone should use. That avoids situations where one reviewer is comparing against the live page while another is comparing against an older draft. Shared version selection leads to clearer comments and faster decisions.

If you need to brush up on how pages are edited and reviewed before using comparisons, revisit [Creating and Editing Documentation Pages](doc:creating-and-editing-documentation-pages) and [Collaborating on Document Changes and Page Quality](doc:collaborating-on-document-changes-and-page-quality). After you finish working through document comparisons, continue with [Understanding Document Preview and Public Page Checks](doc:understanding-document-preview-and-public-page-checks) to validate how the updated page looks before publication.