Code Better with the Google HTML/CSS Style Guide (9 Rules)

Did you know Google publishes an HTML/CSS Style Guide, the same rules its own developers follow? We all edit HTML and CSS on our blogs, but often without any consistent style. Following the Google HTML CSS style guide makes your code easier to read, faster to debug, and simpler for others (or future you) to maintain. I’ve been writing HTML and CSS for over two decades, and these are the rules from the guide I still use every day.

Quick answer: Google’s HTML/CSS Style Guide recommends indenting by 2 spaces (no tabs), using lowercase everywhere, using HTTPS for embedded resources, using CSS shorthand, short hex colours, no units after zero, meaningful hyphenated class names, alphabetical declarations, and validating your code. Tools like Prettier and Stylelint can enforce most of these automatically.

Why follow a style guide?

Clean, consistent code isn’t just about looks. When every file follows the same rules, you can spot mistakes faster, compare changes easily, and pick up code you wrote years ago without confusion. Google keeps its style guides on GitHub for HTML/CSS, JavaScript, TypeScript, Python, Java, C++, Shell and more. The HTML/CSS guide takes about ten minutes to read.

9 coding rules from the Google HTML CSS style guide

1. Indent by 2 spaces

Use two spaces per indent level, not tabs:

<aside>
  <div class="box">
    <p>It's all about style</p>
  </div>
</aside>

2. Use only lowercase

Element names, attributes, selectors, properties and values (except strings) should all be lowercase:

color: #e5e5e5;   /* not #E5E5E5 */

3. Use 3-character hex colours where possible

color: #ebc;      /* not #eebbcc */

4. Use CSS shorthand

Shorthand properties are shorter and easier to read, and smaller files help CSS load faster:

/* Instead of this */
padding-bottom: 1em;
padding-left: 1em;
padding-right: 1em;
padding-top: 1em;

/* Write this */
padding: 1em;

5. Don’t add units after zero

margin: 0;        /* not 0px */

6. Put declarations in alphabetical order

Sorting properties alphabetically makes them quicker to find and avoids duplicates:

.box {
  background: #fff;
  border: 1px solid #ccc;
  color: #000;
  text-transform: uppercase;
}

h1,
h2,
h3 {
  color: #000;
}

Notice the other good habits in that code: block contents indented, a space after each colon, a semicolon after every declaration, each selector and declaration on its own line, and a blank line between rules.

7. Use meaningful, hyphenated class names

Name classes for what they are, not how they look, and separate words with hyphens: .site-nav or .video-player, not .blue-box or .navbarleft. Avoid ID selectors for styling, as they’re hard to override.

8. Use HTTPS and valid, semantic HTML

Load images, scripts and stylesheets over HTTPS. Use elements for their meaning, such as <nav>, <article> and <button>, and give images useful alt text.

9. Mark to-dos with TODO

Google suggests marking unfinished work with TODO followed by your name, such as <!-- TODO(chandra): add footer links -->, so it’s easy to search for later.

Always validate your code

Check your HTML with the W3C Markup Validation Service and your CSS with the W3C CSS Validator. They catch unclosed tags, typos in properties and other errors that browsers silently ignore.

Let tools do the work

You don’t have to remember every rule:

• Prettier formats HTML and CSS automatically with consistent indentation and spacing.
• Stylelint warns about CSS errors and can enforce rules like lowercase hex colours and alphabetical order.
• Most code editors, including VS Code, can format on save.

Clean code also makes optimisation easier, like our tips to load Bootstrap faster.

Frequently asked questions

Does Google use this style guide for rankings?

No. It’s a coding guide for developers, not an SEO rule. But clean, valid HTML helps browsers and search engines read your pages correctly.

Should I use tabs or spaces?

Google’s guide uses 2 spaces. What matters most is being consistent across your project.

Is alphabetical CSS order required?

No, it’s a recommendation. Some teams group properties by type instead. Pick one approach and use it everywhere.