Skip to main content

Confluence Wiki Markup: How to View, Edit & Convert It

· 6 min read
NGPilot

Every Confluence page has two faces: the one you see in the editor, and the one the database sees. The database face is the storage format — an XHTML document with macros as tags — and before it, Confluence stored pages as wiki markup: h1. headings, *bold text*, {code} blocks. People still search for wiki markup because half the internet's Confluence advice, every migration script, and a lot of content written before ~2017 speaks that language. And in 2026 the topic got urgent: Atlassian is retiring the legacy editor (full deprecation April 2026), and the new cloud editor dropped the Markup macro entirely. Here's how to view, edit, and convert what's actually stored — with or without admin rights.

Quick answer: To view a page's markup, open the ••• → View storage format menu (needs space admin) or call GET /wiki/rest/api/content/{pageId}?expand=body.storage. To edit it, use Raw Storage Source Editor, which shows a diff before saving. Legacy wiki markup syntax itself is being retired — the legacy editor is fully deprecated in April 2026 and the new editor no longer accepts the Markup macro.

Method 1 — View Storage Format Natively (Read-Only)​

Open any page, click the ••• (More options) menu in the top right, and pick View storage format. Confluence opens the raw XHTML in a new browser tab: every macro is a <ac:...> or <cx:...> tag, formatting is literal XHTML, and page properties show up as structured blocks.

Two things to know before you go looking for it:

  • It's permission-gated. The option only appears for users with space admin (or explicitly granted) permissions — if the menu item is missing, that's usually why.
  • It's read-only. This is an inspection window. Nothing you do here changes the page, and copy-pasting it elsewhere doesn't give you an editable copy of the page.

Good for: checking what a macro actually stored, diagnosing why something renders oddly, or feeding the XML to a script.

Method 2 — The REST API (No Space Admin Needed)​

The same document is one API call away, and API access is governed by normal page permissions rather than the storage-format menu's admin gate:

curl -u user@example.com:api-token \
  "https://your-site.atlassian.net/wiki/rest/api/content/123456789?expand=body.storage"

The markup comes back in body.storage.value. It's read-only again — but for auditing, diffing two pages, or bulk-reporting which pages still carry legacy macro tags, it's the programmable route.

Method 3 — Edit the Markup Directly (Recommended for Fixes)​

Native editing is where Confluence draws a hard line: the visual editor edits the rendered view, and there's no built-in raw editor on Cloud. When you need to touch the markup — a broken macro from a migration, junk <span> soup from pasted Word content, a bulk rename that must preserve structure — editing the XML by hand through the API means writing blind, and one wrong tag can take the whole page down.

Raw Storage Source Editor for Confluence (free) puts a raw editor inside Confluence instead:

  1. Open a page and launch the editor — the page's storage format loads as editable XML.
  2. Make your change — full find-and-replace for cleanup jobs, direct edits for surgical ones.
  3. Review the diff before saving. You see exactly which lines change, so a slip is a rejected edit instead of a broken page.

It's the same job Atlassian's own Storage Format Source Editor did on Data Center — built for Cloud, where that app never shipped. There's also a Pro version with batch operations for whole-space cleanups.

Method 4 — Legacy Wiki Markup: Convert It Before April 2026​

If your space predates the cloud editor, some pages may still carry legacy wiki markup or the old macro syntax. With the legacy editor's full deprecation set for April 2026, the clock matters more than the syntax:

  1. Inventory first. A REST call scanning body.storage.value for legacy tags (<ac:structured-macro> with deprecated names, raw h1.-style content) tells you how much is left.
  2. Open and let the editor convert. Editing a page in the cloud editor converts what it recognizes into modern macros. Fix anything it can't convert by hand.
  3. Replace markup-dependent workflows. The new editor has no Markup macro, so any process that inserted wiki markup (templates, scripts, copy-paste snippets) needs a new home — modern macros, page templates, or writing in Markdown instead with an app like Enhanced Markdown for Confluence, which renders Mermaid, math, and code natively.

Good for: teams with pre-2017 spaces or migrations from Data Center. If your space is young, this section doesn't apply — and that's the point of checking.

A Pocket Reference: Legacy Syntax → What It Became​

Legacy wiki markupModern equivalent
h1. HeadingHeading (type /heading)
*bold*, _italic_**bold**, _italic_ (or toolbar)
{code:java}...{code}Code block macro (/code)
{panel}, {info}, {warning}Panel, info, and warning panels (/panel)
{table}-style rows ||Standard tables
{color:red}text{color}Text color in the toolbar

The pattern: almost everything has a modern macro equivalent — the syntax is what died. The migration work is mostly mechanical, with the exceptions worth checking page by page.

Which Method Should You Use?​

NeedUse
Peek at what a page really stored••• → View storage format
Read markup without space adminREST API, expand=body.storage
Fix a broken macro or clean up XMLRaw Storage Source Editor (diff before save)
Retire legacy wiki markupInventory via API, convert in the cloud editor before April 2026

The storage format is the page's source of truth — readable natively, editable safely with a diff in front of you, and worth converting now rather than in April. Install Raw Storage Source Editor for Confluence free from the Atlassian Marketplace and open your most structurally-damaged page to see the difference.

Related guides