Style guide

Product names in running text

When Stack Overflow products appear in running text, always capitalize the full product name.

Feature names

Feature names should be capitalized when referring to the specific Stack Overflow feature, but lowercase when used generically. Generic features like questions, answers, tags and search etc should all remain lowercase.

Generic vs specific usage

When using product-related terms generically (not referring to the Stack Overflow product), use lowercase.

Possessives

Use standard possessive rules with Stack Overflow and product names.

Plurals

Avoid pluralizing product names. Use “instances”, “deployments” or similar terms instead.

External communications

Never use abbreviations in external-facing materials including marketing, documentation, blog posts, or sales materials.

Internal communications

In internal Slack, emails, or presentations, abbreviations may be used for brevity once the full name has been established in context. However, defaulting to full names is still preferred.

Headers, subheaders, and tabs

Use sentence case for all headings. This means capitalizing the first word, the first word of a subtitle, and all proper nouns.

Articles vs articles

Capitalize “Articles” when referring to the specific Stack Overflow feature section, but use lowercase when referring to generic articles.

User management and roles

Always capitalize user roles in relation to management systems.

Collectives vs collectives

Always capitalize “Collective” or “Collectives” when used as a proper noun or when it follows a company name. Use lowercase when referring generically to a collective.

Communities & Community

Capitalize “Communities” and “Community” when referring to the Stack Internal feature.

Post scores

Questions, answers, and other types of posts have scores. A post’s score is calculated by subtracting the total number of downvotes from the total number of upvotes.

• In almost all cases when referring to the sum of votes, use the term score
• Use upvote and downvote (one word, no hyphen) when referring to individual types of votes
• Avoid using “points” when referring to score or votes
• The term “votes” to refer to a post’s score is only acceptable in the post summary component format {ScoreValue} votes

Use active voice (most of the time)

Write in the active voice, particularly if the user needs to do something.

While it’s generally best to avoid the passive voice, in certain situations it helps you sound softer without adding too many words. It’s especially useful for time-sensitive messages like payment confirmations and error messages.

Use contractions

Contractions make copy sound more human. Avoid contractions that sound awkward when you say them out loud, or are not commonly used in everyday conversation.

Use American spelling and standards

Use American spelling for all public-facing content. When in doubt, check the Merriam-Webster dictionary for the preferred spelling of specific terms.

Pronouns

Leave off possessives when referring to users or features when possible. If you must use pronouns, refer to users as “you”. Don’t put words in their mouths with phrases that use “I” or “my”.

When referring to Stack Overflow, use “we”. However, try to avoid inserting Stack Overflow into the content as much as possible.

Use “their” as a singular, gender-neutral pronoun when the gender of the subject is unknown or unimportant. Avoid using gendered terms.

Mind your verbs and nouns

Take extra care with “login” and “log in”. The former is a noun while the latter is a verb. Do not use “login” as a verb. The same logic applies to “signup” and “sign up”.

OK

Use the abbreviated version “OK” (fully capitalized in every context). This is preferred to “Okay” and its variants.

Ampersands

Don’t use ampersands (&) unless it’s part of a branded term. Spell out the word “and” instead.

Apostrophes

Use apostrophes to represent omitted letters or numbers (can’t, you’re, ’90s) and to form possessives. See also: use of curly quotes.

Colons

Avoid using colons unless you’re introducing a list. If you need to use a colon in a sentence, Don’t capitalize the first word after it.

Commas

Use the oxford comma in sentences. Don’t use a comma to separate two distinct phrases (comma splicing). Use two sentences instead.

Ellipses

The ellipsis (…) can be used in place of missing text. Avoid using ellipses in regular text. Use the real single character ellipsis unicode (…) opt + ; instead of three periods (…). It’s appropriate to use an ellipsis in input placeholder copy.

Exclamation points

Don’t use exclamation points unless something is really exciting. If you have to use one, limit yourself to one exclamation mark per page.

Hyphens and dashes

Use hyphens to combine two words that modify or describe the noun that follows, or join prefixes and suffixes when there are two vowels beside each other.

Use an en dash with no spaces (–) for a fixed range of numbers. Avoid using em dashes in microcopy for readability, but fine to use in long-form articles or documentation.

Periods

Don’t use periods in interface copy unless it’s a full sentence or description. Don’t use periods in top-level headings, titles, or buttons. Do use periods in body text, descriptions, and help text.

Question marks

Avoid using question marks wherever possible. Reword into affirmative statements wherever you can.

Quotation marks

Always use smart/typographers/curly quotes not vertical, straight quotes. Place punctuation marks outside quotation marks.

Semicolons

Avoid using semicolons. When connecting two closely related ideas, use a comma or write two sentences.

Dates

Use the month’s full name where possible (e.g., October). If there are space constraints, use 3-letter abbreviations with the exception of May (e.g., Oct.). Always write out the full year.

Don’t write dates numerically since differing international standards can lead to confusion. There is no need to add superscripts (st, nd, th, rd) to dates.

Time

Use the 12-hour clock, followed by am or pm. Include a space after the last number (e.g., 1:20 pm). Time should be relative to the user’s time zone (not UTC).

If indicating both date and time, separate them with the word “at” rather than a comma or @ symbol.

Relative dates and times

In most cases, use relative dates and times (e.g., 3 minutes ago) with the exact date and time in the title attribute. When possible, use the longhand time (e.g., 7 years ago). If there are space constraints, use abbreviations: 7y, 3mo, 6d, 6h, 5min, 12s.

Buttons and links

Buttons and links should be clear and predictable. Button and link text should be sentence case and action-led (starting with a verb). Use a verb+noun format except for common actions like Save or Close.

Headings and subheadings

All headings or subheadings should be concise, scannable, and sentence case. Don’t use periods at the end of headings. If a subheading is a full sentence, you may use a period.

Lists

When writing lists:

• Use a colon (:) to introduce an unordered list
• Use sentence case
• If any list item contains two or more sentences, punctuate all list items
• If all list items are one sentence or fragments, don’t punctuate

URLS

The golden rules of URLs is they should be short and rarely (if ever) change. In addition we want them to act as ”URL as UI” which respond to manipulation by the user in an intuitive way.

For example, a user should be able to modify them to navigate e.g., changing /docs/api/v2 to /docs/api/v1, or up and down taxonomy like /questions/tagged/javascript/react to /questions/tagged/javascript to /questions, or changing filters like /jobs?location=remote&type=engineering to /jobs?location=remote.

A good URL can also provide a solid foundation for SEO/AEO.