A style guide is the set of writing rules a team works by: spelling, punctuation, preferred words and the voice it writes in. The best-known style guide examples are the AP Stylebook for news, The Chicago Manual of Style for books, APA Style for academic papers, the Google and Microsoft guides for technical writing, the GOV.UK style guide for public services and Mailchimp's content style guide for a brand voice. Most of the technical, government and brand guides are free to read online.
Each entry ends with the one thing worth borrowing for your own guide. Rules are as each publisher's website gave them in November 2026, and they do change; the AP entry quotes AP through the Digital.gov guide, because the Stylebook itself is sold by subscription.
| Style guide | Published by | Best model for |
|---|---|---|
| Style guideGoogle developer documentation style guide | Published byGoogle | Best model forDeveloper docs, and a clear fallback order |
| Style guideMicrosoft Writing Style Guide | Published byMicrosoft | Best model forA friendly voice, in ten short tips |
| Style guideApple Style Guide | Published byApple | Best model forA–Z entries and international style |
| Style guideGOV.UK style guide | Published byUK Government Digital Service | Best model forPlain English, with a reason for each rule |
| Style guideDigital.gov style guide | Published byUS General Services Administration | Best model forA short guide built on AP |
| Style guideMailchimp Content Style Guide | Published byMailchimp | Best model forVoice and tone across every channel |
| Style guideAP Stylebook | Published byThe Associated Press | Best model forNews writing, and a base for other guides |
| Style guideThe Chicago Manual of Style | Published byUniversity of Chicago Press | Best model forBooks, editing and the humanities |
| Style guideAPA Style | Published byAmerican Psychological Association | Best model forAcademic papers and bias-free language |
Technical writing style guides
Software companies publish some of the most detailed style guides, written for the many people who contribute to their docs. All three of these are free online.
Written for: the people who write Google's public developer documentation, read by software developers and other technical practitioners.
Covers: voice, accessibility, inclusive language and global readers; grammar and punctuation; formatting from headings to procedures; code, placeholders and UI elements; and a word list.
Rules that stand out: second person and active voice, sentence case for titles and headings, serial commas, conditions before instructions, UI elements in bold, code in code font and unambiguous dates. Its tone advice fits in one line: “Be conversational and friendly without being frivolous.”
When it is silent: project-specific style comes first, then Google's guide, then Merriam-Webster.com for spelling, The Chicago Manual of Style for nontechnical questions and the Microsoft Writing Style Guide for technical ones.
What to borrow. The fallback order. No team can write a rule for everything, and Google's guide doesn't try: it says which book to open next. It also calls itself a set of guidelines, not rules, and tells writers to depart from it when that improves the content, which helps keep the guide from becoming a weapon in review. Read it at developers.google.com/style.
Written for: anyone who writes about computer technology, whatever their job title, for anything from an app to a website or a white paper. It replaced the Microsoft Manual of Style.
Voice: “warm and relaxed, crisp and clear, and ready to lend a hand.”
Rules that stand out: its top 10 tips. Cut wordy phrasing. Write the way you speak. Use contractions such as it's and you'll to sound friendly. Put the most important information first. Capitalize as little as possible, with sentence case for headings. Leave periods off titles and headings. Keep the serial comma. One space after a period, none around dashes. Start statements with a verb, and drop needless “you can” and weak openers like “there is.”
Also covers: bias-free communication and writing for a global audience.
What to borrow. The short list on top of the long guide. A new writer can read ten tips in a few minutes, and each one is a concrete decision, not a value. The voice works the same way: three short phrases you can hold a sentence up against. Start at the Microsoft Writing Style Guide welcome page.
Written for: keeping one consistent voice across Apple materials: documentation, reference, training and the words in user interfaces.
Covers: a long A–Z of usage entries; writing inclusively, including about disability; units of measure; technical notation such as code font and placeholder names; international style, from currencies and dates to phone numbers; and trademarks. There is a PDF version.
What to borrow. The international section works as a checklist for anything translated or read in several countries, since every item on it changes from one place to the next. The A–Z format scales, too: a team can start with ten entries and add one each time a question comes up twice. Find it in Apple Support.
Government and plain-language guides
Government guides are written for readers who didn't choose to read: people renewing a passport or applying for a permit. Their rules lean hard toward plain words, and the best ones explain why.
Written for: everyone who publishes on GOV.UK, the UK government's website. It comes in two parts, an A to Z style guide and a technical A to Z, and plain English is mandatory.
Rules that stand out: sentence case everywhere, even in page titles and service names. “And” instead of an ampersand. “One” in words, but numerals from 2 up, 2 to 9 included. Dates without ordinals (2 June) and times like 5:30pm, with “to” in ranges. “Per cent” as two words. Bold only for interface elements the reader has to act on, never for emphasis. No negative contractions such as can't and don't. “Select” instead of “click,” because not every user clicks. And a list of words to avoid.
Reasons given: it swaps eg for “for example” or “such as,” because screen readers can read eg aloud as “egg,” and it avoids ie, which isn't always understood.
What to borrow. The reasons. A rule that explains itself is easier to accept, and writers can apply it to cases the guide never mentions. The guide now lives on the government's content and publishing guidance site, and old links redirect there: start at the A to Z style guide.
Written for: federal employees who write articles for Digital.gov. On voice and tone it says: “Articles for Digital.gov — written by employees from across the federal government — use an informal, conversational tone.”
Base guide: “In general, we follow AP Style.”
Rules that stand out: “Write out all numbers under 10.” “Use the expanded form of Month Day, Year (e.g., February 16, 2022).” Times take a lowercase am and pm. On the serial comma it quotes AP and adds, “So, use your best judgment.” In December 2022 it switched its titles and headers from title case to sentence case.
Also covers: agency names and abbreviations, Digital.gov branding and how to use images.
What to borrow. The length. The guide stays short because one line hands everything else to AP. It also records when a rule changed, so a writer who finds old headlines in title case knows they predate December 2022 and aren't a second standard. Read it at digital.gov/style-guide.
A brand voice style guide
Brand guides spend less time on commas and more on how the company sounds, from error messages to newsletters. Mailchimp's is unusual in being public and openly licensed.
Written for: Mailchimp employees, with an open invitation to other content and communications teams to use and adapt it. The source is on GitHub.
Voice: four traits. Plainspoken, genuine, dry humor, and translators, whose job is to demystify business jargon. Then the distinction that makes the guide: “You have the same voice all the time, but your tone changes.”
Covers: principles, writing about people, grammar and mechanics, web elements, legal and educational content, newsletters, social media, accessibility, translation, a word list and a TL;DR section. It says openly that it breaks some grammar rules for clarity, practicality or preference.
What to borrow. The split between voice and tone, and a section for each channel. A voice that stays fixed while the tone shifts between a billing error and a launch email is one of the most useful ideas in brand writing, and the guide shows it at work. Before you copy text from it, read the license: it requires credit and rules out commercial use of the material. The tone of voice entry covers the distinction in more depth.
News, book and academic guides
These are the big reference books. Most writers meet them through an editor, a publisher or a professor who names one, and then the rule is simple: use the one you are given.
Written for: news writing at the Associated Press, the news agency. It is also a base for other guides: Digital.gov's, for one, follows AP style in general.
Rule that stands out: the serial comma, which AP uses only where it prevents a misreading: “If omitting a comma could lead to confusion or misinterpretation, then use the comma.”
What to borrow. The habit of adopting it whole. AP is a classic base guide: name it in your first line, as Digital.gov does, and your own guide only has to cover what is particular to you.
Written for: writers, editors, proofreaders, indexers, copywriters, designers and publishers. The press calls it a guide to style, usage and grammar, and sells it in print and as an online subscription.
Covers, among much else: two citation systems. Notes and bibliography is preferred by many in the humanities, including literature, history and the arts. Author-date is preferred by many in the sciences and social sciences. Chapters 13 and 14 of the 18th edition set them out.
Also on the site: the Chicago Style Q&A, a long-running collection of style questions and answers.
What to borrow. Chicago is the reference to name when the writing is long and edited in rounds. Google's guide sends writers to it for nontechnical questions, which shows that even a team that never cites a source can adopt it for punctuation and usage and keep its own word list on top.
Written for: students and writers across disciplines, and the people who write, review and edit journal articles.
Covers: paper format, from the title page to headings; in-text citations and reference examples; tables and figures; and bias-free language, with a separate Inclusive Language Guide, now in its second edition.
What to borrow. APA's bias-free language guidance is written as general principles for referring to people respectfully, and it travels well outside psychology. It makes a sound base for the “writing about people” section of any house guide. The guidance starts at apastyle.apa.org.
Where the guides disagree
Put the published guides side by side and the point of a style guide becomes obvious. On many small questions there is no right answer, only a choice, and the guide records which one this house made.
| Decision | One guide says | Another says |
|---|---|---|
| DecisionSerial comma | One guide saysGoogle and Microsoft: always, before the last item in a list | Another saysAP, as Digital.gov quotes it: only where leaving it out could confuse |
| DecisionNumbers under 10 | One guide saysDigital.gov: write them out | Another saysGOV.UK: numerals, 2 to 9 included |
| DecisionContractions | One guide saysMicrosoft: use them, such as it's and you'll, to sound friendly | Another saysGOV.UK: avoid negative ones such as can't and don't |
| DecisionDates | One guide saysDigital.gov: month first, as in February 16, 2022 | Another saysGOV.UK: day first, with no ordinal, as in 2 June |
Take one of those disputes and the readers come into view. Microsoft's guide lists don't among the common contractions it wants for a friendly, informal tone. GOV.UK tells its writers to avoid negative contractions such as can't and don't, because “Many users find them harder to read, or misread them as the opposite of what they say.” Here is the same booking rule written to each house's rule:
Following Microsoft
- You can't change your booking after 5pm the day before.
- Don't forget your passport.
Following GOV.UK
- You cannot change your booking after 5pm the day before.
- Bring your passport.
The words barely change; what a misreading costs does. Microsoft writes about technology for the people using it and wants them to hear a voice that is “warm and relaxed, crisp and clear.” GOV.UK writes for anyone dealing with the government, where one sentence can decide whether someone keeps an appointment, and a reader who misses the n't in the first line turns up at 6pm and loses the slot. The second line shows a side effect: without a negative contraction, the GOV.UK version became a plain instruction rather than “Do not forget.” A team writing help for an app can reasonably follow Microsoft here. A team writing deadlines and eligibility rules has a reason to follow GOV.UK.
Where they agree is just as telling. Google, Microsoft, GOV.UK and Digital.gov all use sentence case for headings, and Digital.gov switched to it in 2022. Dashes are another place where houses differ, and the guide to em dashes and en dashes shows the main options.
What a project style sheet adds
The nine guides above hold decisions that apply to everything a house publishes. A style sheet holds the decisions for one project, such as a single novel, and sits on top of a published guide that settles everything else. An extract from one for an imagined novel set on the coast of Maine:
References. The Chicago Manual of Style, 18th edition. Merriam-Webster.com, first spelling listed, unless this sheet says otherwise.
Names. Delphine Marchetti (“Del” to family only, never in narration). The Varney twins, Hal and Lyle. Gull Rock Light, the lighthouse: “the Light” after first mention in a chapter.
Spelling. gray, not grey. toward, not towards. sternman, one word.
Timeline. Chapter 1 opens on Saturday, October 3, 1987. The storm in chapter 9 is the night of Saturday, October 31.
Query for the author. Ch. 6 has Hal steering the Marguerite; ch. 11 says Lyle owns her. Which twin owns the boat?
The record does three things a house guide can't. It settles questions that exist only in this book, such as who may call Del by that name. It keeps the facts the plot depends on, such as the days of the week, in one place where the proofreader can check them. And its queries catch contradictions, like the boat's owner, before they reach print. A writer can start one during the first draft, long before an editor sees it.
Build yours from these examples
Write the Docs, the documentation community, notes that a lone writer or a small docs group may need no more than a short list of decisions about recurring terms. These steps get you that list, with a published guide doing the rest.
- Name a base guide in the first line
Pick the published guide closest to what you write and say so: “We follow the Microsoft Writing Style Guide, except where this page says otherwise.” Add a dictionary. Google's fallback order is the model.
- Write down only your exceptions
Go through recent drafts and collect the decisions people make differently: “log in” or “login,” numerals or words, the product's name with or without a capital. Each one becomes a line.
Once the guide exists, you can attach it to a chat with the Strokes Assistant and ask it to review a chapter or a help article against it. It flags inconsistencies such as “log in” on one page and “login” on the next.
- Describe the voice with traits and a sample
Use three or four traits, the way Microsoft and Mailchimp do, and give each a “this, not that” line so it can't be read two ways. Then add one paragraph that sounds right. A sample settles more arguments than an adjective.
- Start the word list early
Keep it alphabetical, like the A to Z guides: the term, the forms you don't use and a one-line note. When terms need full definitions for readers, move them into a glossary.
- Give each rule a reason or an example
GOV.UK explains why it says “select.” A reason lets writers apply a rule to cases the guide never covered, and an example shows what the rule looks like in a real sentence.
- Date it and name an owner
Apple dates each version and Digital.gov notes when a rule changed. Put a date and an owner at the top, and add a line to a change log whenever a rule changes.
Write the Docs keeps a longer list of published guides, including Red Hat's open-source technical writing guide and guides from Salesforce, SUSE and GNOME, at writethedocs.org. A content brief should link the finished guide, so freelancers find it before they write.
Common style guide mistakes
- Copying a whole published guide. Few people read 500 borrowed entries. Adopt the guide by reference and write down only what differs.
- Values instead of instructions. “We value clarity” changes nothing on the page. “One idea per paragraph” does.
- Rules without examples. “Be friendly” means different things to a support agent and a lawyer. Show a sentence.
- Two base guides with no tiebreaker. AP for numbers and Chicago for commas works only if the guide says which one wins when they conflict.
- No date, no owner. A guide nobody maintains drifts away from what the team actually writes, and people stop opening it.
- Ignoring the license. Free to read is not free to copy. Mailchimp's license, for one, requires credit and rules out commercial use.
Frequently asked questions
Which style guide should I use?
Use the one your editor, publisher, school or client names. If no one names one, pick by the kind of writing: AP for news-style writing, Chicago for books and long nonfiction, APA for academic papers in fields that use it, such as psychology and nursing, and Google or Microsoft for software documentation. Then write down your own exceptions on top of it.
Is AP style or Chicago style better?
Neither is better; they serve different work. AP comes from a news agency and is built for news writing. Chicago comes from a university press and covers style, usage and grammar for writers, editors and publishers, with two full citation systems. Because they were built for different work, follow the one your publication, publisher or client uses.
Can I use Google's or Microsoft's style guide for my own docs?
You can follow either one: both are free to read, and Google's guide itself sends writers to Microsoft's for technical questions it doesn't cover. Say which one you follow at the top of your own guide and list your exceptions. Copying their text into your guide is a different matter, so check each site's terms first.
