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:

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.

Link text should describe the destination.

On a given page, do not use the same link text for links that go to different destinations.

Place links at the end of sentences, if possible. This helps readers understand the complete thought before deciding whether to follow the link.

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.

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.

Include the file format so the user knows what to expect.

When linking to non-public content, indicate that access is restricted. Use a label such as:

  • Password protected
  • Member only
  • Restricted
  • Internal
  • Login required

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:

Start of a sentence

When starting a sentence with a digit, use words or reword.

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

See punctuation in headings.

See punctuation in links.

Lists

See punctuation in lists.

Numbers

See punctuation in 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”.
email
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.
PDF
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]