W3C Style Guide
About this style guide
Editors: Tamsin Ewing, W3C; Coralie Mercier, W3C. Initial draft: 28 July 2026
This style guide is written for W3C authors and editors. It promotes readability, consistency, and easier translation across all W3C content, including standards-related materials, educational resources, organizational communications, and website content.
This is a living document. For the list of substantive changes, see the Changelog [Link coming].
The guidance is written for US English. Translators should follow the conventions of their target language.
Following this guide helps:
- make content easier to read and understand for people with a wide range of English language proficiency
- support translators by using clear, consistent language
- improve consistency across W3C publications
- reduce editorial corrections and reports of avoidable issues
Keep in mind that W3C content serves a global audience and is often used as authoritative reference material. Prioritize clarity, simplicity, and long-term readability. Much of what we publish becomes part of the permanent web record under the W3C Persistence Policy.
To provide feedback on this style guide, please comment on existing issues or raise a new issue on GitHub.
Structure and presentation
Structure
Logical flow and order
- Present what readers need to know or do first, followed by supporting details and background.
- Make connections between sections clear. For example, use wording that shows how one section builds on, contrasts with, or illustrates another.
Using structural elements
- Headings:
- Use headings and subheadings to group related ideas.
- Write concise, unique headings that clearly describe the content beneath them.
- Front-load headings with relevant keywords to aid readability.
- Sentences:
- Write simple sentences.
- Stick to one idea per sentence.
- Keep the subject and verb close together.
- Use punctuation that helps readers understand how ideas relate to one another.
- If a sentence becomes complex with more than one dependent clause, consider dividing it into two grammatically complete sentences.
- Paragraphs:
- Keep paragraphs short.
- Stick to one topic per paragraph.
- Make sure the paragraph content fits the topic of the heading it sits under.
- Lists:
- Use lists for steps, options, and related items.
Formatting
Bold
Use bold sparingly to highlight important or urgent information, such as names, dates, deadlines, or key actionable points.
Avoid bolding text in whole paragraphs or sections.
Italics
Use italics to indicate foreign words that are not common in English.
Use italics sparingly to emphasize a word or phrase if it helps make the meaning clearer, especially to show differences between ideas.
Avoid italicizing text in whole paragraphs and sections.
Tone, language and words
Tone
- Authoritative and factual
- Clear and straightforward
- Inclusive and respectful
Language
Write in plain language
Plain language uses clear wording, structure and design. It helps readers easily:
- find information
- understand it
- use it to complete tasks
Techniques for writing in plain language
Abbreviations
Provide the full term with the abbreviation on first use. See Expanding abbreviations.
Contractions
Use simple positive contractions such as “it’s”, “you’re”, “we’ve” and they’ll, because they make text feel more conversational and friendly, and help readers absorb information faster.
Avoid negative contractions such as “can’t”, “don’t”, and “won’t”.
Keeping the word “not” expanded is important because it may distinguish between right and wrong, lawful and unlawful, or safe and unsafe. Negative contractions can cause some readers to overlook the apostrophe and interpret a statement as positive.
Personal pronouns
Use “you” and “your” to address the reader.
Use “we” when speaking for an organization (like W3C), but only when it’s clear who “we” refers to.
Structure
Break up information into smaller sections to make it easier to read. See Using structural elements.
Verbs
Do not turn actions into nouns. Use verbs instead.
Voice
Write in the active voice; that is, the subject performs the action.
Avoid the passive voice where possible.
Words
- Use everyday, familiar words.
- Avoid jargon and metaphors.
- Explain specialist terms on first use.
- Remove unnecessary words.
Write for a global audience
W3C content is read and translated around the world.
- Use examples that reflect a variety of cultures and regions.
- Avoid culture-specific references.
- Choose internationally understood terms, such as “postal code” instead of “ZIP code”, and “given name” instead of “first name” (and do not assume everyone has a first and last name, or that a family name comes last).
- Use internationally recognized formats for dates, times, numbers, currency, percentages and measurements to avoid ambiguity.
Write inclusively
Age-inclusive language
Only state or request someone’s age when it’s strictly relevant.
- Use: Older people
- Avoid: Older users, old people, the elderly, seniors
Disability language
Use respectful, accurate language when referring to disability.
Examples:
- Use blind, not “visually impaired”.
- Use deaf, not “hearing-impaired”.
Avoid terms that are dehumanizing or patronizing, or that suggest helplessness or weakness.
Examples:
- the disabled, the blind
- differently abled
- handicapped
- high-functioning, low-functioning
- special needs
- wheelchair bound, confined to a wheelchair
For other disability-specific terms, and terminology to avoid, see the W3C word list.
People-first and identity-first language
Use people-first language on first reference, then use a mix of people-first and identity-first language.
People-first language puts the person before the disability.
Examples:
- people with disabilities
- people who are blind
Identity-first language puts the disability before the person.
Examples:
- disabled people
- blind people
Gender-inclusive language
Use gender-neutral language, where possible.
Avoid assumptions about gender.
Pronouns: Gender inclusivity and translation considerations
Use pronouns that are inclusive and easy to translate for W3C’s global audience.
Use a plural noun to avoid he/she and his/her:
Avoid assuming gender by skipping “he/she” and “his/her”, where possible. Use a plural noun instead.
Use a noun instead of singular “they”:
Singular, “they” can be:
- hard to translate in some languages
- hard to understand for some people
- considered grammatically incorrect by some people
To avoid using singular “they”, use a noun instead.
Exceptions: Use:
- personal pronouns that real people use for themselves
- pronouns assigned to named personas
Race-inclusive language
Terms to avoid:
- Master — instead, use “main”
- Whitelist — instead, use “allowlist”
- Blacklist — instead, use “denylist”
W3C key terms
For correct usage and spelling of key terms, see the W3C word list.
Style for different content types (A–Z)
Abbreviations
Expanding abbreviations
Spell out an abbreviation the first time you use it on a page. Put the short form in parentheses afterwards. After that, you can just use the abbreviation.
There are a few ways you can do this. See Techniques for expanding abbreviations.
Exception: If a term is widely known by its abbreviation, you do not need to spell it out.
Re-expanding abbreviations
- Independent sections: In sections that may be read independently of the main text, spell out the abbreviation again, followed by the abbreviation in parentheses.
- Change of context: If an abbreviation could have multiple meanings and the context changes, provide the full meaning to clarify which meaning is intended.
Capitalization in expanded terms
Use title case for proper names.
Use lowercase for common nouns.
Plural acronyms
Form the plural of an acronym by adding a lowercase “s”. Do not use an uppercase “S” or an apostrophe.
Abbreviations to avoid
- etc.:
- In general contexts, use “such as” to introduce one or more examples.
- Where the text might be used within a legal context, use “including, but not limited to,” to introduce a non-exhaustive list of examples.
- e.g.: Use “for example”.
- i.e.: Use “that is” or “in other words”.
- vs.: Use “versus”, “compared with”, or “in contrast to”.
Exception:
If space is limited (for example, in a table cell), you may use abbreviations carefully.
Include a comma if it would normally follow the full phrase. For example, write “e.g.,” and “i.e.,” rather than “e.g.” and “i.e.”.
Dates
Put the day first:
Use the international format to reduce ambiguity for a global audience. This is a specific, intentional departure from US practice.
Use numbers for the day and year, words for the month:
Do not use letter suffixes after the day:
If numbers only are required, such as in a form, use YYYY-MM-DD:
Relative dates and times
- Use a specific date, including the year, where appropriate, so the information still makes sense over time.
- Avoid relative dates and times, such as tomorrow, last week, or next Thursday, unless the content will be updated promptly.
Exceptions: Blog posts and other dated content can use relative dates because readers expect them to reflect when they were published.
Headings
Correct heading hierarchy
Nest headings properly. For example, <h1> should not be followed by <h3> or lower.
See also the guidance on how to write good headings.
Capitalization in headings
Use sentence case for headings <h1> to <h6>.
Exceptions:
- Capitalize any terms in the heading that are proper names.
- Use title case for the title of a complete, fixed, authoritative work. For details, see Title case versus sentence case — Naming new documents
Punctuation in headings
Use no punctuation at the end of headings, unless a question mark is required.
Labels
Use sentence case for labels in user interface elements. Avoid title case. This includes:
- buttons
- links
- menu items
- form labels
- tabs
- navigation items
Capitalize only the first word and any proper names.
Links
Link text
Link text should describe the destination.
On a given page, do not use the same link text for links that go to different destinations.
In-line links
Place links at the end of sentences, if possible. This helps readers understand the complete thought before deciding whether to follow the link.
Links to definitions
When linking to a definition or glossary entry, link only the first occurrence of the term in each distinct section.
Avoid linking every occurrence of the same term within a paragraph or section. Repeated links create visual clutter and make content harder to scan.
Links for email addresses
When linking to an email address, use the email address itself as the link text rather than the person’s name.
This helps people identify the destination before activating the link and makes it easier to copy or note the address.
Links to non-HTML documents
Include the file format so the user knows what to expect.
Links to non-public documents
When linking to non-public content, indicate that access is restricted. Use a label such as:
- Password protected
- Member only
- Restricted
- Internal
- Login required
Punctuation in links
Add a full stop after the linked text if it ends a sentence. Do not include the full stop as part of the link.
Exception: Never add a full stop after a raw URL.
Lists
Parallel structure
Keep the same grammatical form for each list item: all noun phrases, all verb phrases, or all full sentences.
Long list items
When some items in a list consist of several sentences, consider if the list structure is particularly useful for conveying the information. If not, use regular paragraphs instead of a list.
Capitalization and punctuation in lists
Text that introduces a list
End with a colon.
List items complete the introductory phrase or sentence in the body text
Treat all the items in the list as a grammatical part of the introductory phrase or sentence.
Start with a lowercase letter, even if the list is a numbered list.
End each item with no punctuation.
List items are complete sentences
Capitalize the first letter.
End with a full stop or a question mark.
List items are fragments or not complete sentences
Begin each item with a lowercase letter (unless the first word is normally capitalized, such as a proper noun).
End each item with no punctuation.
List items that are a mix of complete sentences and fragments
If you must mix sentences and fragments, start with a capital letter and end with a full stop or question mark for all items.
Numbers
When to write as digits
Ages, measurements, percentages, and ratios
Always use a digit:
Digits versus words
Numbers showing quantity or order
Numbers up to nine: use words.
Numbers 10 and above: use digits.
Exceptions:
- See Ages, measurements, percentages, and ratios.
- Use words for very large, rounded numbers.
Start of a sentence
When starting a sentence with a digit, use words or reword.
Related numbers
With related numbers, where one number is usually written in digits and the other not, use digits for both.
Adjacent numbers
With adjacent numbers that express different categories of numbers, use a mixture of words and digits.
Phone numbers
Include the country calling code and, where applicable, the area code.
Punctuation in numbers
Use commas as thousands separators in quantities.
Do not use thousand separators in years, addresses, page numbers, or code line identifiers.
Symbols
Except where there is a lack of space (for example, in a table or chart), use words for the following symbols:
- Ampersand:
- &: Use “and” instead.
- Number sign (octothorpe):
- #: Use “number” or a suitable noun instead.
Times
Use the 24-hour clock.
For an audience in a particular location, use the local time zone.
For a global audience, always schedule for the time zone “UTC” (Universal Coordinated Time).
In a sentence, do not use the en dash. Use words instead, such as “from … to” or “between … and” instead.
Titles
Published documents
When referring to the title of a published document, follow the title exactly as it appears and preserve its capitalization, whether it uses title case or sentence case.
If the title uses sentence case and is not linked, enclose it in double quotation marks to distinguish it from the surrounding text.
Naming new documents
Title case
Use title case for the title of a complete, fixed, authoritative work, such as a specification, standard, or policy.
These documents typically have the following characteristics:
- complete works
- formally published and version-controlled
- authoritative, citable documents
Note: When using title case, keep titles as short as practical to improve readability.
Sentence case
Use sentence case for the title of any document that is not a complete, fixed, authoritative work, unless the title includes a proper name.
These documents typically have the following characteristics:
- form part of a larger work, such as a chapter, module, or technique
- describe the information people can find in the document
See related guidance on capitalization in headings.
Grammar
Capitalization
Abbreviations
See Capitalization in abbreviations.
All caps
Avoid using all capital letters for words (except acronyms).
Glossaries
Use lowercase for glossary terms (except for proper names).
Headings
See Capitalization in headings.
Lists
See Capitalization and punctuation in lists.
Official names versus common terms
Capitalize terms when they form part of an official name.
Use the full official name where practical to reduce ambiguity.
Use lowercase for common terms.
When you remove part of an official name, it’s no longer an official name and becomes a common term.
| Example official name | Common term |
|---|---|
| W3C Advisory Committee | advisory committee |
| W3C Code of Conduct | code of conduct |
| WAI Interest Group | interest group |
| W3C Member | member |
| W3C Participant | participant |
| W3C Patent Policy | patent policy |
| W3C Process Document | process document |
| W3C Recommendation | recommendation |
| W3C Staff Contact | staff contact |
| W3C Statement | statement |
| COGA Task Force | task force |
| ARIA Working Group | working group |
| W3C Workshop | workshop |
Plural forms
When you pluralize an official name, it usually becomes a common term.
Use lowercase for common terms.
Working Groups are where formal W3C standards, called Recommendations, are developed and maintained.
Punctuation
Punctuation helps to separate ideas, signal relationships between ideas or emphasize ideas.
Each punctuation type has a different purpose.
Brackets
Parentheses (round brackets)
Use parentheses sparingly within a simple sentence in the following scenarios:
Scenario 1: Provide the abbreviation for a term
Scenario 2: Clarify something in a short aside
Scenario 3: Signal an optional plural
Square brackets
Use square brackets in quotations to show you have altered or added something to the original quoted material.
Use to:
- insert an explanation in a direct quotation
- indicate something that’s been incorrectly written in a direct quotation
- add some text within a direct quotation in order to clarify something
- modify a direct quotation so that it fits grammatically within the surrounding text
Colons and semicolons
Colons
Use a colon to introduce the main idea(s). It gives the sense of “as follows.”
In paragraph text:
- A complete sentence must precede a colon.
- Use lowercase for the word following a colon.
In titles or labels:
- A colon may separate a category label from a title or description.
- Use uppercase for the word following a colon.
Semicolons
Use a semicolon in the following scenarios:
Scenario 1: Use a semicolon to combine two related ideas in a simple sentence. The text before and the text after the semicolon should both be grammatically complete sentences.
Scenario 2: Use a semicolon to break up complex lists in a sentence or bulleted item that contains internal commas.
Commas
In a phrase listing three or more items, place a comma before the final conjunction (“Oxford comma”).
Dashes and hyphens
Em dash (—)
Use an em dash to add clarification, explanation, or emphasis after a complete clause.
Put a space before and after an em dash.
The part after the dash does not have to be a complete sentence.
Note: If combining related ideas with an em dash makes a sentence long or complicated, it is usually better to split it into two sentences.
Em dashes in list items
Use an em dash in a list item to separate a short term or phrase from its explanation or a clarification.
En dash (–)
- Use an en dash to indicate a range in numbers, such as in dates, pages, and sports results.
- Do not add a space before and after an en dash.
Hyphen (-)
Use a hyphen to join compound adjectives.
Note: Be aware that a hyphen can change the meaning of a phrase:
- “small-business owner” versus “small business owner” (an owner of a small business or a business owner who is small?)
- “little-used car” versus “little used car” (a car that has been used very little, or a used car that is small?)
Do not hyphenate:
- an adverb that ends in “ly”
- an adverb that follows a noun
Use a hanging hyphen when two compound adjectives modify the same noun.
For guidance on terms we no longer hyphenate and now write as one word, see the W3C word list.
Ellipsis (…)
Use an ellipsis to show:
- missing words
- a pause
- something left unsaid
Add a space before and after an ellipsis.
Headings
Links
See punctuation in links.
Lists
See punctuation in lists.
Numbers
Quotation marks
Double quotation marks
Use double quotation marks to reference a term.
Single quotation marks
Use single quotation marks for a quotation inside a quotation.
Note: With nested quotes, the full stop remains inside both the single and double quotation marks.
Scare quotes
Avoid using quotes in a way that could be taken to suggest irony or in a non-standard way. For more information, see scare quotes.
Slashes
Forward slash
Generally, use a forward slash only in dates, fractions, and URLs.
Avoid using a forward slash as a substitute for words.
For two things that have a close relationship, use a hyphen or words like “and” or “or” instead.
Example 4: Alternative
- Use: If or when I have a dog, I’ll need a fenced yard.
- Avoid: If/when I have a dog, I’ll need a fenced yard.
Exception: You may use a forward slash to show an alternative if it’s clearer than using words.
That versus which
That: Introduces essential information needed to understand the sentence.
Which: Introduces extra information that is not essential.
Verb agreement with collective nouns
Use a singular verb with collective nouns when referring to the group as a single entity.
Exceptions:
Exception 1: Use a plural verb if members act independently.
Exception 2: The collective noun, “people”, always takes a plural verb.
W3C word list
This alphabetical list of words describes the correct usage and spelling of terms used in W3C work that are commonly misspelled or misused.
- accessible
- Use “accessible” only when referring to accessibility for people with disabilities, or to places that disabled people can easily reach or enter. Do not use it to mean “convenient”, “available”, or “easy to use”. For example, avoid: “The gardens are accessible to the public.” Instead, use: “The gardens are open to the public.”
- abort
- Avoid. Use “cancel”.
- anti-alias
- Hyphenate.
- ASCII
- Use all caps.
- back end, back-end
- Use “back end” as a noun: “Data is processed by the back end.” Use back-end as an adjective: “We rely on a back-end server.” See Hyphen.
- base64
- Lowercase and write as one word.
- Bézier
- Always capitalize and include the accent on the first “e”.
- blacklist
- Avoid. Use “denylist”. See Race-inclusive language.
- braille
- Lowercase, unless referring to Louis Braille.
- built-in
- Hyphenate when used as an adjective or noun. Do not hyphenate when “built” is a verb. See Hyphen.
- checkbox
- Write as one word.
- click (versus select)
- Use “click” when instructing a user to activate an interactive element, such as a button or link. For example, avoid “Select the Submit button.” Instead use: “Click the Submit button.”
- color blind
- Avoid when referring to people. Use “people who cannot distinguish between certain colors (often called ‘color blindness’).” When referring to the medical condition, use “color vision deficiency”. See Disability language.
- color space
- Write as two words.
- data
- Treat as singular. Write “The data is transferred,” not “The data are transferred.” See Verb agreement with collective nouns.
- dingbat
- Write as one word.
- DTDs
- Do not use an apostrophe. See Plural acronyms.
- ECMAScript
- Write as one word and capitalize the “S”.
- Write as one word. Do not hyphenate.
- end user
- Write as two words.
- et al.
- Do not place a full stop after “et”.
- filename
- Write as one word.
- for instance
- Avoid. Use “for example”. See Words in plain language.
- front end, front-end
- Use front end as a noun. Use front-end as an adjective. See Hyphen.
- full stop (.)
- Use full stop as the formal name.
- grandfather
- Avoid. Use legacy. See Gender-inclusive language.
- hand-eye coordination
- Use “hand-eye coordination”, not “eye-hand coordination”.
- hard-coded
- Hyphenate.
- hash (#)
- Also called a number sign. Usually avoid “pound sign”, “crosshatch”, and “octothorpe”.
- header
- Use header for table headers and HTTP headers.
- heading
- Use heading for headings marked up with
<h1>through<h6>. - hearing-impaired, hearing impairment
- Avoid. Use “deaf” with a lowercase “d”, unless a person or community prefers another term. See Disability language.
- homepage, home page
- One word preferred, both allowed.
- hostname
- Write as one word.
- HTTP/1.0, HTTP/3
- Use the slash when referring to the protocol name. Omit it only where established usage in running text requires a different form.
- internet
- Lowercase.
- italics
- Use the plural form.
- its, it’s
- Use “its” as the possessive form. Use “it’s” as the contraction of “it is” or “it has”. For example, “It’s a dog wagging its tail. It’s happy to see its owner.”
- Java
- Capitalize the “J”.
- JavaScript
- Capitalize the “J” and the “S”.
- Level 1, Level 2, Level 3
- Capitalize “Level” when referring to a level in a W3C technical report.
- line feed
- Write as two words.
- log in, login
- Use “log in” as a verb. Use “login” as a noun or adjective.
- loss
- Avoid as a general description that includes congenital conditions. Use it when describing a change, such as “As we age, we may experience hearing loss.” See Disability language.
- lowercase
- Write as one word.
- markup
- Write as one word. Do not hyphenate.
- master
- Avoid. Use main. See Race-inclusive language.
- metadata
- Write as one word. Do not hyphenate.
- million
- Do not abbreviate within a sentence. Use a capital “M” for “mega” only with care and where the meaning is clear.
- MIME type
- Prefer “Internet media type”. If using “MIME type”, write it as two words and use all caps for “MIME”.
- mouse click
- Write as two words. Check whether you mean a mouse click specifically or any form of activation, including a finger tap or key press.
- mouse pad
- Write as two words.
- namespace
- Lowercase, unless referring to the “Namespaces in XML” specification by name.
- number sign (#)
- Also called a hash. Usually avoid “pound sign”, “crosshatch”, and “octothorpe”.
- nobody
- Write as one word.
- no one
- Write as two words.
- offline
- Write as one word. Do not hyphenate.
- online
- Write as one word. Do not hyphenate.
- onscreen
- Write as one word when used as an adjective.
- pathname
- Write as one word.
- Use all caps. It does not need to be expanded on first use. See similar exceptions in Expanding abbreviations.
- persons
- Avoid. Use “people”.
- please
- Usually omit in informational content and instructions when it’s an unnecessary word. See Words.
- plug-in
- Hyphenate.
- read-only
- Hyphenate.
- real-time communication
- Lowercase, including when used with the acronym: real-time communication (RTC). Capitalize only when part of a proper name.
- refer to
- Avoid where “see” is clearer. See Words.
- ruby
- Lowercase for the typographic convention. Capitalize for the Ruby programming language.
- sanity
- Avoid in phrases such as “sanity check”. Use a more precise term, such as “coherence”, “confidence check”, or “validation”. See Disability language.
- schema
- Lowercase, unless part of a proper name.
- schemas
- Prefer “schemas” to “schemata”.
- select (versus click)
- Use “select” when choosing from a set of options. For example, “Select an option from the dropdown menu.”
- semicolon
- Write as one word.
- slave
- Avoid. Use a context-specific alternative, such as “replica”. See Race-inclusive language.
- speech recognition
- Use for technology that converts spoken words into text for speech-to-text transcription, virtual assistants, and other speech user interfaces.
- standalone, stand-alone
- One word preferred, both allowed.
- style sheet
- Write as two words, except in the official name, Extensible Stylesheet Language.
- subset
- Write as one word. Do not hyphenate.
- superset
- Write as one word. Do not hyphenate.
- timestamp
- Write as one word.
- timezone
- Write as one word.
- touchscreen
- Write as one word.
- uppercase
- Write as one word.
- URI reference
- Usually write “URI reference”, not “URI Reference” or “URI-Reference”.
- URIs
- Do not use an apostrophe. See Plural acronyms.
- usable
- Use “usable”, not “useable”.
- user agent
- Lowercase, unless part of a proper name.
- user interface
- Lowercase, unless part of a proper name.
- visually impaired
- Avoid. Use “blind” or a more specific term that reflects the person or group being described. See Disability language.
- voice recognition
- Use for technology that identifies who is speaking by analyzing vocal characteristics, such as voice biometrics used for authentication.
- W3C
- Use “W3C”, not “the W3C”. For example, “There are more than 50 staff at W3C”. But it’s okay to say “the World Wide Web Consortium”.
- W3C Note
- Use “W3C Note”, not “W3C NOTE”.
- web
- Lowercase, except when referring to the invention, as in “Sir Tim Berners-Lee invented the Web,” or when it is part of a proper name, such as “World Wide Web Consortium” or a job title such as “Senior Web Developer.”
- web page
- Write as two words.
- webmaster
- Write as one word.
- website
- Write as one word.
- white space
- Write as two words when used as a noun.
- whitelist
- Avoid. Use “allowlist”. See Race-inclusive language.
- World Wide Web
- Write as three words. Do not hyphenate.
- worldwide
- Write as one word.
- zeros
- Use “zeros”, not “zeroes”.
Acknowledgments
Thank you to Tamsin Ewing, W3C Senior Accessibility Content Specialist, and Coralie Mercier, W3C Director of Marketing and Communications, who authored this guide in July 2026.
We are also grateful to contributors who have improved the guidance [List to be added as part of the GitHub issue triage and disposition]