Style Guide Meta-Analysis 2026: What 33 Guides Reveal

In short: 15 rules form the industry consensus — led by direct second-person address in 85 % of guides. Dissent runs along one axis (formal-technical vs. conversational-brand-led). Six topic areas — AI content, dark mode, RTL layout, voice interfaces, sustainability, collaboration language — are covered by zero of 33 guides. The synthesised Style Guide 2026 is available as a free AsciiDoc download.

Your style guide is the least-read document in your content and product organization. We read 33 of them — publicly accessible content and writing style guides from major technology companies, design systems, editorial houses, and accessibility organizations. From Apple and Google to WCAG, from Mailchimp to the BBC. 1,636 extracted rules. 321 verbatim quotes. 13 thematic axes.

Three findings stand out. First: there is a surprisingly stable industry consensus of 15 core rules, ones that Apple, Google, Mailchimp, and the US government all agree on, often word for word. Second: dissent runs along a single axis — formal-technical vs. conversational-brand-led — and wherever it runs, it produces opposing rules for contractions, emoji, quotation marks, and exclamation marks. Third: entire topic areas of the present (AI content, voice interfaces, RTL layout, dark mode) are essentially absent from the corpus.

If you are writing a style guide in 2026, you can take the first 80 percent from the consensus. The remaining 20 percent are the ones that matter. (For a primer on the broader discipline, see our Technical Writing Guide.)

How we built the study

We analyzed 33 publicly accessible style guides. The corpus covers the full functional spectrum:

• Tech-doc guides (Google, Microsoft, GitLab, GitHub, MongoDB, Splunk, Red Hat, Rackspace, Aiven, DigitalOcean)
• Brand and voice guides (Mailchimp, Monzo, Buffer, The Writer)
• Design-system content guides (Atlassian, Shopify Polaris)
• Accessibility specifications (WCAG 2.1, MDN)
• Journalistic-editorial manuals (BBC)
• Academic textbook PDF (Michigan State University)
• Pure word lists (Apple Style Guide, Container Terminology, Coda Human Words)
• Meta-directories (Conscious Style Guide, Styleguides.io, Write The Docs)

Each guide was distilled into a JSON structure that counts rules per category, retains verbatim quotes, and aggregates thematic clusters. 13 categories structure the analysis: Voice & Tone, Inclusive Language, Grammar, Punctuation, Formatting, Structure, Code Conventions, Accessibility, Linking, Numbers/Dates/Measures, UI Content, Global/Localization, Naming & Terminology. Consensus is what at least 50 percent of the guides explicitly prescribe — not a mere keyword hit, but a substantively framed rule. Dissent is when at least three guides specify one direction and at least three the opposite. Single rules from exactly one guide are niche practice.

The consensus: 15 rules the industry rallies around

From the matrix, 15 rules emerge as industry practice in 2024/25. But “consensus” has two levels: three rules cross the explicit 50 %-of-guides threshold in wording. The remaining eleven are widely followed — they just aren’t always written down with the same clarity. The chart below makes that split visible.

Tone and address

“Be direct (‘add apps’ not ‘you can add apps’).” — Shopify Polaris

Direct second-person address. 28 of 33 guides (85 percent) address the reader as “you” — from Apple and Google to Microsoft and Splunk to Plain Language and Mailchimp. “The user” and the third person are actively rejected. Shopify Polaris puts the stance plainly: “Be direct (‘add apps’ not ‘you can add apps’)”. Google’s Developer Documentation Style Guide is explicit: “Use ‘you’, instead of ‘the user’ or ‘they’”.

Active voice as default, passive as a justified exception. 16 guides explicitly mandate active voice; only GitHub (audit logs) and MSU (executive summaries) frame legitimate exceptions. The US Federal Plain Language Guide canonizes the default in a memo: “Not ‘It must be done,’ but ‘You must do it.’” GitLab gives the pragmatic rationale: “text is easier to understand and to translate if you use active voice instead of passive.”

Ditch formal cheerleader words (“successfully”, “Success!”). Atlassian, Shopify, and Mailchimp recommend reducing UI messages to the action, not the celebration. Atlassian’s mnemonic is unique in the corpus: “These are low commitment experiences, we want to give flowers not puppies.”

Clarity and readability

“Be friendly and conversational. No. Robot. Words.” — Microsoft Writing Style Guide

Plain language, simple vocabulary, no buzzwords. 18 guides argue against jargon, idioms, and inflated wording. Microsoft summarises the school in three points: “Be friendly and conversational. No. Robot. Words.” Google sharpens with examples: “use ‘start’ not ‘commence’, ‘use’ not ‘utilize’”. The Federal Plain Language Guide provides the principled rationale: “Complexity is the greatest enemy of clear communication.”

Avoid idioms, metaphors, and Latin abbreviations. At least eight guides explicitly, many more implicitly. Atlassian banishes “piece of cake” as well as “e.g.”, “i.e.”, “etc.”, “&” as not localization-friendly. GitHub: “Avoid regional idioms, slang, stacked nouns”. Google goes so far as to question even industry-standard terms: “Don’t use casing-style names like ‘camel case’ or ‘snake case’ in docs — they don’t translate well.”

Numbers 0–9 spelled out, 10 and up as digits. The classic Microsoft/AP default is the rule at Atlassian, Datagrok, GitLab, and MSU. Splunk consistently uses digits for all measurements and version numbers; Apple makes decimal and phone numbers special cases.

Inclusion

“Don’t use terms like ‘sanity check’, which associates mental health with being functional.” — Apple Style Guide

Gender-neutral language, singular „they” as default. 20 guides (61 percent) require gender-neutral language; at least eight (Apple, Atlassian, Buffer, Datagrok, MongoDB, Splunk, The Writer, Conscious Style) explicitly endorse singular „they”. Apple: “it’s OK to use they, their, or them as a singular, gender-neutral pronoun.”

No mental, racialised, or violence-normalising metaphors. Five tech guides (Apple, GitLab, Google, Monzo, Splunk) systematically replace terms like sanity check, blacklist/whitelist, or kill. Apple: “don’t use terms like ‘sanity check’, which associates mental health with being functional.” Monzo adds: “We use ‘blocklist’ and ‘allowlist’ instead”. This is the strongest newly established consensus point of the past five years.

Person-first or identity-first — depending on context. Six guides address the debate, all land at the same compromise: ask the community. Apple and Conscious Style explicitly leave the choice open. Splunk defaults to identity-first when the community prefers it (“autistic person”, “Deaf community”). Buffer summarises the shared stance: “Labels are for boxes, not people.”

Accessibility

“No ARIA is better than bad ARIA.” — MDN Web Docs

Descriptive link text, never „click here” or „learn more”. 16 guides document this rule — MDN, Accessible Social, Aiven, Mailchimp, Plain Language, Shopify, Splunk, and others. Aiven: “Never use ‘here’ as link text”. The rationale is consistent: people using screen readers often navigate via a list of links, so context-free links become unusable.

Alt-text for informative images. 15 guides codify alt-text; Shopify, Splunk, and MDN sharpen the distinction against decorative images. Accessible Social is unmistakable: “Auto-generated alt text created by an artificial intelligence program should never be used in place of a custom image description written by a human.”

Unbroken heading hierarchy, contrast 4.5 : 1, keyboard operability. MDN: “Headings must not break hierarchical structure”. GitLab: “H1 comes from page metadata; do not add an H1 in Markdown and do not skip heading levels.” The contrast threshold of 4.5:1 (normal text) and 3:1 (large text) is named identically by MDN, Atlassian, Google, and WCAG.

Typography and formatting

“When in doubt, don’t capitalize.” — Microsoft Writing Style Guide

The Oxford / serial comma is standard. All seven guides that explicitly address the topic — Apple, Mailchimp, MSU, Microsoft, MongoDB, Shopify, The Writer — favour it. Not a single guide in the corpus forbids the Oxford comma. The Writer notably calls it a “grey area” but uses it. (For typographic details across documents, see our Typography Guide.)

Non-breaking space between number and unit. Atlassian, Google, GitLab, MSU, and Splunk match word for word — Splunk literally: “Add a nonbreaking space between the numeral and the rate measurement.” GitLab shows the example: “128 GB”.

Sentence case in headings and UI labels. Eight guides set sentence case as the default. Microsoft’s mnemonic is as compact as it is universal: “When in doubt, don’t capitalize.” It’s a tight consensus against the US-American title-case heritage.

Exclamation marks: sparingly, if at all. Every guide that takes a position points the same way. Three ban them outright (Developer Style Guide, Splunk, The Writer); four limit them to at most one per page (Atlassian, Shopify, Google, Aiven). Not one guide in the corpus recommends emphatic use. Developer Style Guide captures the register: “technical documentation is not a gossip magazine.” Google adds the accessibility angle: some screen readers don’t read out punctuation.

And one bonus rule that runs across all clusters: four guides (Apple, GitLab, Google, Splunk) explicitly require that product names never be used as verbs and never as possessives. Google: “Don’t use product names or feature names as verbs.” Splunk: “Don’t use ‘Splunk’ in the possessive form, which can dilute the trademark.”

The dissent: one axis, four symptoms

The dissent in the corpus is not randomly distributed; it follows a clear fault line: formal-technical (academic, traditional, risk-averse) versus conversational-brand-led (consumer-product, voice-led). Almost every single conflict is a projection of this underlying tension.

Contractions: allowed or taboo

“Use contractions, where possible, as they convey a conversational, friendly tone.” — Atlassian Design System

The “allowed” camp comprises nine guides (Apple, Atlassian, Datagrok, GitLab, Microsoft, Shopify, Splunk, Mailchimp, The Writer). Atlassian’s reasoning stands for the group: “Use contractions, where possible, as they convey a conversational, friendly tone.” Splunk specifies: only in present and future, not past tense. The “forbidden” camp comprises MSU, the Red Hat Documentation Guidelines, and parts of DigitalOcean. MSU is the strictest: “Contractions are not to be used in technical writing.” The fault line runs precisely between product and marketing documentation on one side and academic-scientific reporting on the other.

Quotation marks: straight or typographic

“Don’t use curly quotes. Use straight quotes instead.” — Datagrok Writing Style

The “curly/smart” camp comprises Apple and Atlassian for prose and UI. Apple: “Use curly opening and closing quotation marks except in code font.” The “straight” camp comprises GitLab, Google, Splunk, and Datagrok. Datagrok: “Don’t use curly quotes. Use straight quotes instead.” The split is functional: developer docs don’t want breakage in terminal output, brand copy wants typographic cleanliness.

Title case versus sentence case

“Use sentence case for document titles and headings.” — Google Developer Documentation Style Guide

Eight guides require sentence case (Atlassian, Datagrok, Developer Style Guide, Google, Mailchimp sub-nav, Microsoft, Shopify, Accessible Social). Four hold to title case (Linode, Mailchimp main nav, Container Terminology, GitLab for product names). Mailchimp internally practices a third way: title case only for main navigation and form titles, sentence case for sub-navigation, checkboxes, and radio buttons. Microsoft remains dogmatic: “When in doubt, don’t capitalize.”

Emoji: use intentionally or avoid

“With intention — to highlight, not to decorate.” — CLI Guidelines

Five guides ban emoji (DigitalOcean, GitLab, GitHub, Developer Style Guide, Splunk in the chatbot context); six allow them deliberately (Mailchimp, Buffer, Aiven, CLI Guidelines, Accessible Social, Monzo). CLI Guidelines formulates perhaps the best guideline in the entire corpus: emoji “with intention — to highlight, not to decorate.” Accessible Social sets pragmatic limits: max three emoji per post, no emoji-only columns, never at the start of a line, where screen readers often skip them.

The fault line is the classic register fault line: docs no, marketing and community yes. And if you look closely: those who allow emoji usually also allow contractions and sentence case. Those who ban exclamation marks usually also ban curly quotes. The dissent is, in truth, a register cluster.

Which topics are well tended — and which neglected

Not every category is documented equally densely. Product and brand names are by far the densest axis (92 percent of all guides make at least one statement on the topic). Global/Localization sits at the bottom (49 percent) — paradoxical for a corpus in which translation is regularly cited as the rationale for other rules.

What the table tells us: the basics are densely documented. Voice, structure, formatting, grammar — these are the fields where almost every guide takes a stance. The edges grow thinner: code conventions (54 percent), numbers and date formats (51 percent), localization (49 percent). The category that should be central in a globalised content world is the one most rarely treated systematically.

The main message: what every guide regulates is tonality and terminology. What too few regulate is translatability and technical notation.

What no guide says in 2026

The corpus has blind spots that are conspicuous in 2026.

AI and LLM content. None of the 33 guides formulates rules for handling LLM-generated content, prompt notation, or the citation of hallucinated passages. Accessible Social touches the topic negatively (“Never rely on auto-generated alt text”), Splunk has a chatbot tonality section — that’s it. In a year when every major content organization works with Copilot and Perplexity output, this is a conspicuous gap.

Voice interfaces. Outside Splunk’s chatbot chapter, voice UIs appear nowhere. No rule on prosody, on pause punctuation, on screen-reader-first phrasing in UI text.

Dark mode, color tokens, semantic colors. Zero systematic rules. Design systems talk about colors but not about color-token language (“color.status.error”) or about dark-mode contrast strategies.

RTL layout and CJK line-breaking. Zero native hits. RTL (right-to-left) covers Arabic and Hebrew scripts; CJK stands for Chinese, Japanese, and Korean — languages where typography, line breaks, and punctuation differ fundamentally from Latin script. Google and Splunk recommend avoiding directional cues (“to the right”) — that’s the only RTL note. Arabic, Hebrew, CJK typography rules: nothing.

Sustainability and content weight. Zero guides. No rule on image budgets, none on text compressibility, none on the carbon footprint of media content.

Collaboration language. No guides on PR titles, commit messages, review tone. A field where millions of words are produced daily — without a style guide.

The takeaway: if you write a style guide in 2026, you have an open field here, and no excuse to leave it empty.

Eight types, one corpus

The 33 guides are not a homogeneous group. They cluster into eight clearly distinguishable types, and each type has different strengths and blind spots.

The tech-doc faction (ten guides) is dense on code conventions, terminology, and localization. It writes precisely; it is more disciplined than the rest. But it is silent on brand voice, humor, and emoji register — Mailchimp’s “winking, not shouting” doesn’t happen here. The brand and voice faction (four guides) regulates tonality spectra, UI microcopy, and inclusive brand voice with a warmth tech-doc doesn’t know. It rarely codifies a precise placeholder style.

The design systems (Atlassian, Shopify Polaris) are the rare case where both come together: UI content with a clear brand voice, error messages with accessibility discipline. The accessibility specs (WCAG, MDN, Accessible Social) define the technical rules of the web, but they do not describe how a brand sounds.

Editorial guides (BBC, MSU, Plain Language, Datagrok) are old, proven, and conservative; they are silent on UI content and code. Word lists (Apple Style Guide, Human Words, Container Terminology) are reference works, not philosophies. Meta-directories (Conscious Style, Styleguides.io, Write the Docs) make no decisions of their own — they reference. CLI and developer guides (CLI Guidelines, Linode, Developer Style Guide) have a tone of their own: imperative, terse, unironic.

If you build a style guide, you choose your type first. A product guide is not an editorial manual, and neither is an accessibility spec. The consensus rules are everywhere the same — but the weighting, the examples, and the tone follow the type.

Seven building blocks for 2026

From the matrix, seven recommendations emerge that any modern guide should address.

1. You-address, active voice, sentence case as the baseline. No debate. 85 percent of the industry has decided.
2. Inclusive terminology with a concrete substitution list. No “sanity check”, no “blacklist”, no “master/slave” — with the replacement word next to it. Without a substitution list, the guide stays vague.
3. Accessibility as grammar, not as appendix. Link text, alt-text, heading hierarchy, and contrast in the same review as typos.
4. Explicit register decision. Contractions yes or no? Emoji yes or no? Curly or straight quotes? Exclamation marks? These four decisions distinguish your product register from the neighbour’s. Document them.
5. AI content policy. Hallucination review, labeling, manual alt-text mandate, prompt-as-code rule. No guide in the industry has it — you can be the first. See how AI augments technical writers for the editorial context.
6. Phrase for localization. No idioms, no directional cues, no stacked nouns, room for 30 % expansion in UI strings. The thinnest axis in the corpus is the one with the most consequences.
7. Pre-publish checklist. Ten questions, not fifty. Michigan State does it, Mailchimp does it, Atlassian does it. A guide without a checklist is not an actionable guide.

Frequently asked questions

How many style guides recommend direct second-person address?
28 of 33 guides (85 percent) address the reader as “you” — from Apple and Google to Microsoft, Splunk, Plain Language, and Mailchimp. “The user” and third person are actively rejected across the corpus.

Which style guides address AI- and LLM-generated content?
None of the 33 analysed guides formulates systematic rules for LLM-generated content, prompt notation, or citation of hallucinated passages. Accessible Social touches the topic negatively (“Never rely on auto-generated alt text”) and Splunk has a chatbot tonality section — that is all.

Is the Oxford comma the industry standard?
Yes. All seven guides that explicitly address the topic (Apple, Mailchimp, MSU, Microsoft, MongoDB, Shopify, The Writer) favour it. Not a single guide in the 33-guide corpus forbids the Oxford comma.

Sentence case or title case for headings?
Eight guides require sentence case (Atlassian, Google, Microsoft, Shopify and others). Four hold to title case (Linode, Mailchimp main navigation, Container Terminology, GitLab for product names). The industry trend in 2026 clearly favours sentence case.

Which topics are covered by none of the 33 style guides?
Six topic areas have zero systematic coverage in the corpus: AI and LLM content, dark mode and colour tokens, RTL layout and CJK typography, sustainability and content weight, collaboration language (commit messages, PR titles, review tone), and generative UI text. Voice interfaces, video captions and neurodiversity appear in exactly one guide each.

We distilled the findings into an actionable internal style guide — 17 paragraphs from voice & tone to AI content, with explicit Our rule decisions wherever the industry disagrees. Eight pro tips from individual guides that would otherwise drown in the noise (Atlassian’s “Flowers not puppies” for success messages, DigitalOcean’s sammy as default example name, Linode’s “Lazy numbering” in Markdown lists).

The file is written in AsciiDoc and can be opened, customized, and exported as PDF or HTML directly in adoc Studio. Tables, admonitions (NOTE/TIP/IMPORTANT/WARNING), quote blocks, and an automatic table of contents are already configured in the document header. For teams that split style guides across multiple files, the modular documentation approach works natively with AsciiDoc includes.

The boring truth: your guide will probably consist 80 percent of consensus rules everyone else also has. The value is in the remaining 20 — in explicit decisions about register, terminology, AI content, and accessibility. Write them down, justify them, and let Mailchimp set the tone: “We prefer winking to shouting.”