Master Confluence wiki syntax with this complete reference guide. Learn formatting, tables, code blocks, and how to embed docs from tools like DocuWriter.ai.
A developer opens a Confluence page to answer one simple question. Instead, they get a wall of text, a pasted stack trace, three inconsistent heading styles, and a table that broke the moment someone edited it. The information may be correct, but the page still fails because nobody can scan it.
That’s where confluence wiki syntax still matters. Even with modern editors, shorthand markup remains one of the fastest ways to impose structure on technical content, especially in legacy pages, admin areas, and environments where raw control matters more than buttons. It turns plain text into navigable documentation with headings, lists, tables, code blocks, and reusable content patterns.
Manual formatting has limits, though. It’s precise, but it’s also labor. Teams that document complex APIs, services, or internal platforms eventually hit the same bottleneck: engineers spend too much time formatting and not enough time maintaining substance. If you’re evaluating documentation workflows more broadly, this roundup of best documentation software is a useful starting point. And if your team is weighing workspace decisions, this Confluence vs Notion comparison is worth reading for the trade-offs in structure, collaboration, and technical depth.
Good documentation has two jobs. It must be correct, and it must be easy to use.
Confluence pages often fail at the second job first. A runbook with weak headings slows incident response. An API page with broken list nesting forces readers to guess hierarchy. A setup guide with raw code pasted into paragraphs becomes harder to trust, even when the instructions are accurate.
Confluence wiki syntax gives writers keyboard-first control. Instead of reaching for toolbar controls, you can type structure directly:
That speed matters most in engineering environments. Technical writers, developers, and DevOps teams often revise pages while context is fresh. A shorthand syntax lowers the friction between “I know what this page should say” and “the page is now readable.”
Knowing the syntax helps, but it doesn’t remove the maintenance burden. Someone still has to:
That’s why mature teams treat manual syntax as a useful skill, not the end state. Use it when you need direct control. Don’t confuse that with an efficient documentation system.
Confluence Wiki Markup is Atlassian’s shorthand formatting language for creating structured content without relying on the visual editor. Atlassian formally documented it around 2005 to 2006, and the syntax supports over 20 distinct elements. Even after Confluence page storage shifted to XHTML-based representation, wiki markup remained important for rapid formatting and administration, and Confluence powered documentation for over 150,000 organizations by 2023 according to Atlassian’s documentation on Confluence Markup.
That history explains why confluence wiki syntax still shows up in places new users don’t expect.
You won’t use wiki markup for every page in the latest editor, but you’ll still run into it in practical situations:
If you inherit a mature Confluence instance, markup literacy stops being optional.
Wiki markup works best when the goal is structured plain text with predictable formatting. It shines in:
It’s less comfortable when layouts get highly visual or when many casual contributors need discoverable editing tools.
Markup is efficient for experienced users and opaque for everyone else.
A visual editor helps occasional contributors because commands are visible. Wiki syntax helps frequent contributors because commands are memorized. Neither approach is universally better. The right choice depends on how often people write, how technical the content is, and whether consistency depends on disciplined authorship.
That’s why the strongest Confluence environments pair syntax knowledge with templates, style rules, and careful content ownership.
The fastest way to improve a Confluence page is to fix its hierarchy. Most weak pages don’t lack information. They lack visible structure.
Atlassian’s documented core syntax includes h1. through h6. for headings, along with *bold*, _italics_, -strikethrough-, +underline+, {{monospace}}, ^superscript^, and ~subscript~ in its guide to Confluence wiki markup. These are the building blocks of readable technical pages.
Use headings to reflect document logic, not visual preference.
A practical rule is simple:
When writers misuse headings for styling, page navigation becomes unreliable.
Short formatting cues help readers separate meaning from noise.
Use these sparingly.
{{Monospace}} is the right choice for commands, filenames, variables, and inline code.Here’s a common pattern for setup instructions:
npm ci.And here’s what not to do:
h5. or h6. just to shrink text.{{monospace}} or code blocks are available.Readable pages feel calm. Syntax gives you that control.
Paragraphs explain. Lists decide. Tables compare.
That distinction matters in technical docs. If a page includes prerequisites, options, parameters, or rollout steps, prose alone slows readers down. Confluence wiki syntax gives you a compact way to create structure that holds up under revision.
Bulleted lists use *. Numbered lists use #. Nesting comes from repeating the symbol.
A simple bulleted list:
* Install the CLI
* Authenticate to the workspace
* Run the initial syncA numbered process:
# Open the admin console
# Create a new token
# Store the token securely
# Update the service configurationNested lists let you separate main actions from details:
# Deploy the service
## Confirm environment variables
## Verify secrets are mounted
# Run post-deploy checks
## Check logs
## Test the health endpointMixed lists are useful when one numbered step contains unordered notes:
# Prepare the migration
* Back up the database
* Freeze schema changes
# Apply the patch
* Watch application logs
* Confirm user login worksMany teams frequently get sloppy. They mix indentation styles, break hierarchy, and force readers to infer what is primary versus secondary.
Long procedural pages often become unreadable because every detail gets the same visual weight.
Use lists for:
Don’t use lists for dense explanation that belongs in prose.
Tables use pipe syntax. Header cells use double pipes.