HTML Guides

NaN in JavaScript stands for “Not a Number” and appears when a numeric operation fails — for example, parsing a non-numeric string with parseFloat(), dividing 0 by 0, or referencing an undefined variable in arithmetic. When this NaN value gets concatenated with a unit string like "rem", the result is "NaNrem", which is meaningless to CSS. The browser cannot interpret it, and the W3C validator flags it as an invalid letter-spacing value.

This issue almost always originates from dynamically generated styles — either through JavaScript that sets inline styles, a server-side template that computes CSS values, or a CSS-in-JS library. The rendered HTML ends up containing something like style="letter-spacing: NaNrem", which the validator rightly rejects.

Beyond validation, this is a practical problem: the browser will ignore the invalid declaration entirely, so whatever letter-spacing you intended won’t be applied. Your layout may look different than expected, and the invalid value in the markup signals a bug in your code that could affect other computed styles too.

How to Fix It

1. Trace the source of the value. Search your codebase for where letter-spacing is set. If it’s an inline style, look at the JavaScript or server-side code that generates it.

2. Validate the number before using it. In JavaScript, use Number.isNaN() or isFinite() to check that a computed value is valid before applying it.

3. Provide a sensible fallback. If the calculation might fail, default to a known-good value like 0 or normal.

4. Fix the root cause. Determine why the calculation produces NaN — common causes include missing data attributes, undefined variables, or parsing non-numeric strings.

Examples

❌ Invalid: NaN concatenated with a unit

This is what the rendered HTML looks like when the bug occurs:

<p style="letter-spacing: NaNrem">Spaced text</p>

The JavaScript that likely produced it:

// Bug: getAttribute returns null if data-spacing is missing
let spacing = parseFloat(element.getAttribute('data-spacing'));
element.style.letterSpacing = spacing + 'rem'; // "NaNrem" if attribute is missing

✅ Fixed: Validate the value before applying it

let raw = parseFloat(element.getAttribute('data-spacing'));
let spacing = Number.isFinite(raw) ? raw : 0.1; // fallback to 0.1
element.style.letterSpacing = spacing + 'rem';

This produces valid inline CSS:

<p style="letter-spacing: 0.1rem">Spaced text</p>

✅ Fixed: Using a static CSS value

If the letter-spacing doesn’t need to be dynamic, the simplest fix is to use a plain CSS rule instead of computing it in JavaScript:

<style>
  .spaced-text {
    letter-spacing: 0.1rem;
  }
</style>
<p class="spaced-text">Spaced text</p>

✅ Fixed: Server-side template with a guard

If a server-side template generates the style, add a check before rendering:

<!-- Pseudocode for a template engine -->

<!-- Only output the style attribute if the value is a valid number -->

<p style="letter-spacing: 0.05rem">Spaced text</p>

Ensure your template logic verifies the value is numeric before injecting it into the markup. If the value is missing or invalid, either omit the style attribute entirely or use a safe default.

Valid letter-spacing values for reference

The letter-spacing property accepts:

• The keyword normal (default, lets the browser decide)
• Any valid CSS length: 0.1rem, 1px, 0.05em, 2px, etc.
• 0 (no extra spacing)

The numeric part must always be a real number — NaN, Infinity, and empty strings are never valid.

A lexical error is a low-level parsing failure. Unlike a syntax error where the structure is wrong but the characters are individually valid, a lexical error means the parser cannot even form valid tokens from the input. The CSS specification defines a precise set of characters and sequences that are meaningful — property names, values, punctuation like ;, :, {, }, and so on. When the parser encounters something outside these expectations, such as @ where a ; should be, a curly (“smart”) quote instead of a straight quote, or a stray Unicode character, it raises a lexical error.

This matters for several reasons. First, browsers handle invalid CSS unpredictably — some may skip the entire rule block, others may ignore only the broken declaration, and the behavior can vary across browser versions. This leads to inconsistent rendering for your users. Second, a single lexical error can cascade, causing the parser to misinterpret subsequent valid CSS as well, potentially breaking styles well beyond the offending line. Third, clean, valid CSS is easier to maintain, debug, and collaborate on.

Common causes of this error include:

• Invalid characters used in place of punctuation — e.g., @, !, or # where a semicolon or colon should be.
• Smart (curly) quotes — pasting CSS from word processors or CMS editors that convert "straight quotes" to "curly quotes" or 'curly apostrophes'.
• Missing semicolons — while not always a lexical error, a missing ; can cause the next line’s property name to be read as part of the previous value, producing unexpected character sequences.
• Non-ASCII invisible characters — byte order marks (BOM), zero-width spaces, or non-breaking spaces that are invisible in most editors but invalid in CSS tokens.
• Copy-paste artifacts — copying code from PDFs, websites, or chat applications that insert hidden formatting characters.

To fix the issue, go to the exact line and column the error references. Look at the character it reports as “Encountered” and determine what the correct character should be. If you can’t see anything wrong, try deleting the characters around the reported position and retyping them manually — this eliminates invisible character problems.

Examples

Invalid character instead of semicolon

The @ symbol after blue is not valid CSS punctuation in this context:

<style>
  h1 {
    color: blue@
    font-size: 24px;
  }
</style>

Replace @ with a proper semicolon:

<style>
  h1 {
    color: blue;
    font-size: 24px;
  }
</style>

Smart quotes in font-family

Curly quotes copied from a word processor cause a lexical error:

<style>
  body {
    font-family: \u201CHelvetica Neue\u201D, sans-serif;
  }
</style>

Use straight double quotes instead:

<style>
  body {
    font-family: "Helvetica Neue", sans-serif;
  }
</style>

Stray character in an inline style

An accidental backtick in a style attribute triggers the error:

<p style="color: red`; margin: 0;">Hello</p>

Remove the invalid character:

<p style="color: red; margin: 0;">Hello</p>

Invisible non-breaking space

Sometimes the error points to what looks like empty space. A non-breaking space (\u00A0) pasted from another source can hide between tokens:

<style>
  .box {
    display:\u00A0flex;
  }
</style>

Delete the space and retype it as a normal ASCII space:

<style>
  .box {
    display: flex;
  }
</style>

If you suspect invisible characters, use your text editor’s “show whitespace” or “show invisible characters” feature, or paste the CSS into a hex editor to inspect the raw bytes. Configuring your editor to save files in UTF-8 without BOM also helps prevent encoding-related lexical errors.

The line-height CSS property controls the spacing between lines of text within an element. When the validator reports that a value “is not a line-height value,” it means the value you provided doesn’t match any of the accepted formats defined in the CSS specification.

Common mistakes that trigger this error include:

• Misspelled keywords — writing norml or Normal instead of normal (CSS keywords are case-insensitive in browsers, but some validators may flag inconsistencies; the real issue is outright misspellings).
• Invalid or missing units — using a unit the spec doesn’t support (e.g., line-height: 1.5x;) or accidentally adding a unit to what should be a unitless value (e.g., confusing 1.5 with 1.5 em with a space).
• Malformed numbers — typos like 1..5 or 24ppx.
• Using unsupported keywords — values like auto, thin, or large are not valid for line-height.
• Negative values — line-height does not accept negative numbers.

This matters for standards compliance and predictable rendering. While browsers may silently ignore an invalid line-height value and fall back to a default, this means your intended styling won’t be applied — potentially causing overlapping text, poor readability, or inconsistent layouts across browsers. Fixing validation errors ensures your styles work as intended everywhere.

Valid line-height values

The unitless number format is generally preferred because it scales properly with inherited font sizes, avoiding unexpected results in nested elements.

Examples

❌ Incorrect: invalid values that trigger the error

<!-- Misspelled keyword -->

<p style="line-height: norml;">Text with an invalid line-height.</p>

<!-- Invalid unit -->

<p style="line-height: 1.5x;">Text with an unrecognized unit.</p>

<!-- Malformed number -->

<p style="line-height: 1..5;">Text with a typo in the number.</p>

<!-- Unsupported keyword -->

<p style="line-height: auto;">Auto is not valid for line-height.</p>

<!-- Negative value -->

<p style="line-height: -1.5;">Negative values are not allowed.</p>

✅ Correct: valid line-height values

<!-- Keyword -->

<p style="line-height: normal;">Browser default line height.</p>

<!-- Unitless number (recommended) -->

<p style="line-height: 1.5;">1.5 times the font size.</p>

<!-- Length with px -->

<p style="line-height: 24px;">Fixed 24px line height.</p>

<!-- Length with em -->

<p style="line-height: 1.5em;">1.5em line height.</p>

<!-- Percentage -->

<p style="line-height: 150%;">150% of the font size.</p>

Full document example

<!DOCTYPE html>
<html lang="en">
<head>
  <title>Valid line-height Example</title>
</head>
<body>
  <h1 style="line-height: 1.2;">A Heading with Tight Spacing</h1>
  <p style="line-height: 1.6;">This paragraph uses a unitless line-height of 1.6,
    which is a common choice for body text readability. It scales correctly even
    if child elements have different font sizes.</p>
</body>
</html>

Tip: unitless vs. percentage/length

A unitless line-height and a percentage line-height may look equivalent, but they behave differently with inherited styles. A unitless value is recalculated for each child element based on its own font size, while a percentage or length is computed once on the parent and that fixed value is inherited. For most cases, unitless numbers are the safest choice.

The W3C validator raises this error when it encounters a bare unit like px used as the value for margin-bottom without an accompanying number. In CSS, length values are always composed of two parts: a <number> and a <unit>. The token px alone is not a valid <length> value — it’s just a unit identifier with no magnitude. This typically happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that outputs an empty variable before the unit.

This matters for several reasons. First, browsers will discard the invalid declaration entirely, meaning margin-bottom will fall back to its default or inherited value — likely not what you intended. This can cause unexpected layout shifts across different pages or components. Second, invalid CSS can make debugging harder, since the silent failure may not be obvious until the layout breaks in a specific context. Third, clean, valid CSS is easier to maintain and signals code quality to collaborators.

How to fix it

1. Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
2. Use 0 without a unit if you want zero margin: margin-bottom: 0 is valid and preferred over margin-bottom: 0px.
3. Use a keyword value if appropriate: margin-bottom also accepts auto, inherit, initial, revert, and unset.
4. Check template variables: if you’re using a preprocessor like Sass or a JavaScript framework that injects values, make sure the variable isn’t empty or undefined before concatenation with the unit.

Examples

Incorrect: bare unit with no number

<div style="margin-bottom: px;">Content</div>

The value px is not a valid margin-bottom value. The browser will ignore this declaration.

Correct: numeric value with unit

<div style="margin-bottom: 10px;">Content</div>

Correct: zero margin (no unit needed)

<div style="margin-bottom: 0;">Content</div>

Correct: using a keyword value

<div style="margin-bottom: auto;">Content</div>

Incorrect in a stylesheet

<html lang="en">
<head>
  <title>Example</title>
  <style>
    .card {
      margin-bottom: px;
    }
  </style>
</head>
<body>
  <div class="card">Content</div>
</body>
</html>

Fixed stylesheet

<html lang="en">
<head>
  <title>Example</title>
  <style>
    .card {
      margin-bottom: 16px;
    }
  </style>
</head>
<body>
  <div class="card">Content</div>
</body>
</html>

Watch out for preprocessor issues

If you use a CSS preprocessor like Sass or Less, a common source of this error is an empty or undefined variable:

/* If $spacing resolves to empty, this produces "margin-bottom: px;" */
.card {
  margin-bottom: $spacing + px;
}

Instead, ensure the variable includes the unit or has a valid fallback:

$spacing: 16px;

.card {
  margin-bottom: $spacing;
}

The same principle applies to any CSS property that expects a <length> value — always pair a number with its unit, or use 0 when no spacing is needed.

The spacing() function is not a valid CSS value. It does not exist in any CSS specification.

The spacing() notation is commonly found in utility-based frameworks like Tailwind CSS or custom design systems where it acts as a shorthand for spacing scales. However, browsers and the W3C validator do not recognize it as valid CSS.

If you’re using a build tool or preprocessor, make sure spacing() is being compiled into a valid CSS value before it reaches the browser. If you’re writing plain CSS, replace it with a standard CSS length value such as px, rem, em, or use a CSS custom property.

How to Fix

Replace spacing(3) with a valid CSS length value:

#content::after {
  margin-bottom: 0.75rem;
}

Or use a CSS custom property to create your own spacing scale:

:root {
  --spacing-3: 0.75rem;
}

#content::after {
  margin-bottom: var(--spacing-3);
}

Both approaches produce valid CSS that the W3C validator will accept. If your project relies on a framework that provides spacing(), check that your build pipeline (e.g., PostCSS, Sass, or Tailwind) is correctly transforming it into standard CSS before deployment.

When the W3C validator reports that "px" is not a valid margin-left value, it means the CSS declaration is missing its numeric component. A bare unit like px is meaningless on its own — CSS needs to know how many pixels you want. This typically happens due to a typo, an accidental deletion, or a templating/build tool that outputted an empty variable before the unit.

This matters because browsers will discard the entire declaration as invalid, meaning margin-left will fall back to its default or inherited value. This can cause unexpected layout shifts and make your design behave inconsistently. The issue applies equally to any CSS length property, not just margin-left.

Valid values for margin-left

The margin-left property accepts:

• A length value: a number followed by a unit, such as 10px, 2em, 1.5rem, 5vw
• A percentage: e.g., 5%
• The keyword auto
• The value 0 (which requires no unit)

A unit without a preceding number (like px, em, or %) is never valid.

Examples

Incorrect: unit with no number

<div style="margin-left: px;">Content</div>

The browser cannot interpret px alone and will ignore the declaration entirely.

Correct: number with a unit

<div style="margin-left: 10px;">Content</div>

Correct: zero margin (no unit needed)

<div style="margin-left: 0;">Content</div>

Incorrect: empty variable in a template

This issue often appears when a dynamic value is missing. For example, in a template:

<!-- If "spacing" is empty, this produces "margin-left: px;" -->

<div style="margin-left: {{spacing}}px;">Content</div>

To guard against this, ensure the variable always contains a valid number, or provide a fallback default.

Correct: using CSS custom properties with a fallback

If you’re working with CSS custom properties, you can use var() with a fallback value to prevent invalid declarations:

<div style="margin-left: var(--spacing, 10px);">Content</div>

Correct: in an external stylesheet

If the issue is in a linked stylesheet rather than inline styles, the same fix applies:

/* Incorrect */
.sidebar {
  margin-left: px;
}

/* Correct */
.sidebar {
  margin-left: 20px;
}

Quick checklist

• Ensure every length value has a number before the unit (e.g., 16px, 1em, 2rem).
• If you want no margin, use 0 — it’s the only numeric value that doesn’t need a unit.
• If using templates or preprocessors, verify that variables resolve to actual numbers before being concatenated with units.
• Consider using CSS calc() if you need computed values: margin-left: calc(2em + 4px);.

CSS length values must always pair a number with a unit — writing just px, em, %, or any other unit without a preceding number is meaningless to the browser and will be ignored. This typically happens due to a typo, a copy-paste error, or a build tool / template that outputs a unit without its corresponding numeric value (e.g., a variable that resolved to an empty string concatenated with px).

When the W3C validator encounters margin: px in an inline style attribute, it flags the error because px on its own does not match any valid CSS value for the margin property. Valid values include lengths like 10px or 2em, percentages like 5%, the keyword auto, or the number 0 (which doesn’t need a unit). Browsers will discard the invalid declaration, meaning your intended spacing won’t be applied — potentially breaking your layout in subtle ways that are hard to debug.

This issue also applies to other CSS properties that accept length values, such as padding, width, height, top, left, border-width, font-size, and many more. The fix is always the same: ensure every unit has an accompanying number.

How to Fix It

1. Add the missing number before the unit: change px to something like 10px, 1.5em, or 20%.
2. Use 0 without a unit if you want zero margin — writing margin: 0 is valid and preferred over margin: 0px.
3. Use a keyword if appropriate, such as margin: auto for centering.
4. Remove the declaration if the margin value was unintentional or unnecessary.

If the value comes from a preprocessor, template engine, or JavaScript, check that the variable being interpolated is not empty or undefined before it gets concatenated with the unit string.

Examples

Incorrect: Unit Without a Number

<div style="margin: px;">Content</div>

The value px has no number, so this is invalid CSS.

Correct: Number Paired With Unit

<div style="margin: 10px;">Content</div>

Correct: Zero Margin (No Unit Needed)

<div style="margin: 0;">Content</div>

Correct: Using a Keyword

<div style="margin: auto;">Content</div>

Incorrect in an External Stylesheet

This same error can appear in a <style> block or linked stylesheet:

<style>
  .card {
    margin: px;
  }
</style>

Correct in an External Stylesheet

<style>
  .card {
    margin: 16px;
  }
</style>

Watch Out for Template Variables

A common cause in templating systems is an empty variable:

<!-- If spacing is empty, this produces "margin: px;" -->

<div style="margin: {{ spacing }}px;">Content</div>

To prevent this, ensure the variable contains the full value including the number, or add a fallback:

<div style="margin: 16px;">Content</div>

When you write margin-right: px, the browser cannot determine what margin to apply because px alone is not a recognized CSS value — it’s just a unit suffix without a quantity. CSS length values are always a combination of a number and a unit (e.g., 10px, 1.5em, 20%), or a specific keyword like auto, inherit, or 0 (which doesn’t require a unit). The lone px is meaningless on its own and will be ignored by browsers, which means your intended spacing won’t be applied.

This issue typically arises in a few common scenarios:

• A number was accidentally deleted during editing, leaving behind just the unit.
• A CSS preprocessor variable or template expression failed to output a value, resulting in only the unit being rendered.
• A typo or copy-paste error stripped the numeric portion.

Beyond simply not working, invalid CSS can cause unpredictable rendering differences across browsers. It also makes your code harder to maintain, as other developers may not understand the intended value.

To fix this, determine what numeric value you intended and place it directly before the px unit with no space between the number and unit. If no margin is needed, either remove the property entirely or set it to 0.

Examples

Incorrect: unit without a number

<div style="margin-right: px;">Content</div>

The validator reports that px is not a valid margin-right value because no number precedes the unit.

Fixed: complete value with number and unit

<div style="margin-right: 10px;">Content</div>

Fixed: using zero (no unit required)

<div style="margin-right: 0;">Content</div>

When the value is 0, no unit is needed since zero is the same in all units.

Fixed: using a keyword value

<div style="margin-right: auto;">Content</div>

The auto keyword is a valid value for margin-right and is commonly used for centering or pushing elements.

Watch for preprocessor or template issues

If you’re using a CSS preprocessor or a templating language, make sure your variables resolve to complete values:

/* Incorrect — if $spacing is empty, this outputs "margin-right: px;" */
.sidebar {
  margin-right: px;
}

/* Correct */
.sidebar {
  margin-right: 16px;
}

Other valid units

Any valid CSS length unit works, as long as a number precedes it:

<div style="margin-right: 2em;">Em-based margin</div>
<div style="margin-right: 5%;">Percentage-based margin</div>
<div style="margin-right: 1.5rem;">Rem-based margin</div>

The margin shorthand property sets the margin area on all four sides of an element. It accepts one to four values, where each value must be a valid CSS length (e.g., 10px, 1em, 0), a percentage, or the keyword auto. When the validator reports “Too many values or values are not recognized,” it means either more than four values were supplied, or at least one of the values is something CSS doesn’t understand — such as a misspelled unit, a missing unit on a non-zero number, or an invalid keyword.

Common causes of this error include:

• Too many values: Providing five or more values (e.g., margin: 1px 2px 3px 4px 5px). The shorthand accepts a maximum of four.
• Missing units: Writing a non-zero number without a unit (e.g., margin: 10 instead of margin: 10px). Only 0 is valid without a unit.
• Typos or invalid units: Using a misspelled or nonexistent unit like margin: 10xp or margin: 10pixels.
• Invalid keywords: Using a keyword that isn’t recognized in the margin context (e.g., margin: none). The only non-global keyword margin accepts is auto.
• Missing separators or extra characters: Including commas or other unexpected characters between values (e.g., margin: 10px, 20px). Values should be separated by spaces, not commas.

This matters because browsers may ignore or misinterpret an invalid margin declaration entirely, leading to broken or inconsistent layouts across different browsers. Writing valid CSS ensures predictable rendering and easier maintenance.

How margin shorthand values work

The number of values you provide determines how they are applied:

• 1 value: Applied to all four sides. margin: 10px → top, right, bottom, and left all get 10px.
• 2 values: First is top and bottom, second is left and right. margin: 10px 20px → top/bottom 10px, left/right 20px.
• 3 values: First is top, second is left and right, third is bottom. margin: 10px 20px 30px.
• 4 values: Applied clockwise — top, right, bottom, left. margin: 10px 20px 30px 40px.

Examples

❌ Too many values

/* Five values — invalid */
.box {
  margin: 10px 20px 30px 40px 50px;
}

❌ Missing unit on a non-zero number

.box {
  margin: 10 20px;
}

❌ Invalid keyword

.box {
  margin: none;
}

❌ Comma-separated values

.box {
  margin: 10px, 20px;
}

✅ Correct: one to four valid values

/* All four sides */
.box {
  margin: 10px;
}

/* Top/bottom and left/right */
.box {
  margin: 10px 20px;
}

/* Top, left/right, bottom */
.box {
  margin: 10px auto 20px;
}

/* Top, right, bottom, left */
.box {
  margin: 10px 20px 30px 40px;
}

✅ Correct: using auto for centering

.container {
  margin: 0 auto;
}

✅ Correct: zero without a unit

.box {
  margin: 0;
}

✅ Correct: using global keywords

.box {
  margin: inherit;
}

If you need to set margins on more than four sides independently (which isn’t possible — elements only have four sides), you likely have a logic error. If you want fine-grained control, use the individual longhand properties (margin-top, margin-right, margin-bottom, margin-left) instead of the shorthand.

The margin-top property accepts several types of values: lengths (like 10px, 1.5em, 2rem), percentages (like 5%), the keyword auto, or the value 0. When you write margin-top: px, the browser encounters a bare unit with no associated number, which is meaningless — it doesn’t know how many pixels you want. Browsers will ignore the invalid declaration entirely, which means margin-top will fall back to its default or inherited value. This can lead to unexpected layout results that may differ across browsers.

This error commonly happens due to a typo, an accidental deletion of the numeric portion, or a templating/build tool that failed to interpolate a variable (e.g., margin-top: ${value}px where value was empty). It can also occur when editing CSS quickly and removing the number while intending to change it.

Beyond just margin-top, this same principle applies to all CSS properties that accept length values — margin, padding, width, height, font-size, border-width, and many others. A bare unit without a number is never valid.

Note: The value 0 is the only numeric length that does not require a unit. Writing margin-top: 0 is perfectly valid and equivalent to margin-top: 0px.

How to fix it

1. Add the missing number before the unit. Determine the spacing you need and prepend it to the unit (e.g., 10px, 1.5em).
2. Use a valid keyword if you don’t need a specific numeric value — auto or inherit, for example.
3. Check template variables if you use a preprocessor or templating system. Make sure the variable that provides the number is defined and not empty.

Examples

Incorrect: bare unit with no number

<div style="margin-top: px;">Content</div>

The validator reports that "px" is not a valid margin-top value because it lacks a numeric component.

Correct: number followed by a unit

<div style="margin-top: 10px;">Content</div>

Correct: using zero without a unit

<div style="margin-top: 0;">Content</div>

Correct: using a keyword value

<div style="margin-top: auto;">Content</div>

Incorrect in a stylesheet

<style>
  .box {
    margin-top: px;
  }
</style>
<div class="box">Content</div>

Correct in a stylesheet

<style>
  .box {
    margin-top: 16px;
  }
</style>
<div class="box">Content</div>

Incorrect with CSS preprocessor output

If you use a preprocessor like Sass or a JavaScript framework, an undefined or empty variable can produce this error:

<!-- If the variable was empty, the rendered output becomes: -->

<div style="margin-top: px;">Content</div>

Ensure the variable has a valid numeric value so the rendered CSS is complete:

<div style="margin-top: 20px;">Content</div>

In CSS, property values such as lengths, percentages, and keywords are written without quotation marks. Quotes in CSS are reserved for specific contexts like content property strings, font family names with spaces, and url() paths. When you wrap a margin value (or any similar CSS property value) in double or single quotes, the CSS parser interprets it as a string literal rather than a set of length or keyword values. Since "0 0 1em 0" is a string and not a valid margin value, the declaration is ignored by browsers and flagged by the W3C validator.

This is a problem for several reasons. First, the style will silently fail — browsers discard CSS declarations they can’t parse, so your intended margins won’t be applied, potentially breaking your layout. Second, it indicates a misunderstanding of CSS syntax that could lead to similar errors in other properties. This mistake commonly occurs when developers confuse HTML attribute quoting rules with CSS value syntax, especially when writing inline style attributes where the attribute value itself is already quoted.

The margin property accepts one to four values, each of which can be a length (e.g., 10px, 1em), a percentage, auto, or a global keyword like inherit. None of these require quotes. The fix is straightforward: remove the quotation marks around the CSS value.

Examples

❌ Incorrect: margin value wrapped in quotes

In a <style> block:

<style>
  .card {
    margin: "0 0 1em 0";
  }
</style>

In an inline style:

<p style="margin: '10px auto'">Hello</p>

Both of these produce the validator error because the CSS parser sees a quoted string instead of valid margin values.

✅ Correct: margin value without quotes

In a <style> block:

<style>
  .card {
    margin: 0 0 1em 0;
  }
</style>

In an inline style:

<p style="margin: 10px auto">Hello</p>

Valid margin value formats

For reference, here are the accepted patterns for the margin property — none of which use quotes:

/* All four sides */
margin: 1em;

/* Vertical | Horizontal */
margin: 5% auto;

/* Top | Horizontal | Bottom */
margin: 1em auto 2em;

/* Top | Right | Bottom | Left */
margin: 2px 1em 0 auto;

/* Global keywords */
margin: inherit;
margin: initial;
margin: unset;

Watch out for inline style quoting confusion

A common source of this mistake is confusion about the quotes used for the HTML style attribute versus the CSS values inside it. The outer quotes delimit the attribute value for HTML — the CSS inside should not have its own quotes around property values:

<!-- ❌ Wrong: extra quotes around the CSS value -->

<div style="margin: '1em'"></div>

<!-- ✅ Correct: only the HTML attribute is quoted -->

<div style="margin: 1em"></div>

This same rule applies to other CSS properties like padding, border, font-size, color, and so on. If you see a similar validator error for any CSS property, check whether you’ve accidentally quoted the value.

The mask-image CSS property sets one or more mask layers for an element, controlling which parts are visible based on the mask’s alpha channel or luminance. According to the CSS Masking specification, the property accepts a comma-separated list of mask references, where each individual value must be one of:

• none — No mask layer is applied.
• A <image> value — This includes url() references to image files (PNG, SVG, etc.) and CSS image functions like image().
• A CSS gradient — Functions like linear-gradient(), radial-gradient(), conic-gradient(), and their repeating variants (repeating-linear-gradient(), etc.).

When the validator encounters a value that doesn’t match any of these accepted forms, it flags the error. This matters because browsers will silently discard invalid mask-image declarations, meaning your intended masking effect won’t apply, and the element will render as if no mask were set.

Common causes

Typos in gradient or function names are a frequent trigger. For example, writing linear-gradiant() instead of linear-gradient(), or radial-grad() instead of radial-gradient().

Bare image paths without url() will also cause this error. The value mask.png is not valid on its own — it must be wrapped as url('mask.png').

Unsupported keywords or arbitrary strings like mask-image: circle or mask-image: overlay are not valid. The only keyword mask-image accepts is none.

Malformed gradient syntax such as missing parentheses, invalid color stops, or incorrect direction keywords can also produce this error. For instance, linear-gradient(right, red, blue) is invalid because directional keywords require the to prefix.

Vendor-prefixed values used without the matching prefix on the property can trigger issues as well. Using -webkit-gradient() as a value for the standard mask-image property may not validate.

Examples

Incorrect: bare image path without url()

<div style="mask-image: mask.png;">
  Content here
</div>

Correct: image path wrapped in url()

<div style="mask-image: url('mask.png');">
  Content here
</div>

Incorrect: typo in gradient function name

<div style="mask-image: linear-gradiant(to right, transparent, black);">
  Content here
</div>

Correct: properly spelled gradient function

<div style="mask-image: linear-gradient(to right, transparent, black);">
  Content here
</div>

Incorrect: missing to keyword in gradient direction

<div style="mask-image: linear-gradient(right, transparent, black);">
  Content here
</div>

Correct: direction uses the to keyword

<div style="mask-image: linear-gradient(to right, transparent, black);">
  Content here
</div>

Incorrect: unsupported keyword

<div style="mask-image: overlay;">
  Content here
</div>

Correct: using none to explicitly disable masking

<div style="mask-image: none;">
  Content here
</div>

Correct: multiple mask layers

<div style="mask-image: url('star.svg'), linear-gradient(to bottom, black, transparent);">
  Content here
</div>

Correct: radial gradient as a mask

<div style="mask-image: radial-gradient(circle, black 50%, transparent 100%);">
  Content here
</div>

Note that browser support for the unprefixed mask-image property has improved significantly, but some older browsers may still require the -webkit-mask-image prefix. When using the prefixed version, make sure to also include the standard property for forward compatibility. The W3C validator checks against the standard syntax, so always ensure your standard mask-image declaration uses valid values even if you also include prefixed versions.

The mask CSS shorthand property allows you to hide parts of an element by masking or clipping it at specific points. It combines several longhand properties into one declaration: mask-image, mask-mode, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and mask-composite.

Because mask is a shorthand that accepts values for many sub-properties, it’s easy to trigger validation errors. Common causes include:

• Too many values: Providing more values than the shorthand grammar allows, or duplicating values for the same sub-property.
• Unrecognized values: Using vendor-specific values (like -webkit- prefixed keywords), typos, or values that belong to a different CSS property.
• Incorrect value order: The shorthand has a specific grammar. For example, mask-size values must follow mask-position values and be separated by a /, similar to the background shorthand.
• Mixing shorthand and longhand concepts: Trying to set values that aren’t part of the mask shorthand grammar.

The formal syntax for a single mask layer is:

<mask-layer> = <mask-reference> || <position> [ / <bg-size> ]? || <repeat-style> ||
               <geometry-box> || [ <geometry-box> | no-clip ] || <compositing-operator> ||
               <masking-mode>

This is a problem for standards compliance because invalid CSS can lead to the entire declaration being ignored by browsers, causing your masking effect to silently fail. It also affects cross-browser compatibility — different browsers have varying levels of support for the mask shorthand, and using individual longhand properties is often more reliable.

To fix this issue:

1. Check each value in your mask declaration and ensure it’s a valid value for one of the mask sub-properties.
2. Use longhand properties instead of the shorthand if you only need to set one or two aspects of the mask. This avoids ambiguity and improves readability.
3. Separate position and size with / if you’re specifying both, e.g., center / contain.
4. Remove or separate vendor prefixes — use -webkit-mask for WebKit-specific syntax and the standard mask for standards-compliant syntax, but don’t mix prefixed values into the unprefixed property.

Examples

Incorrect: too many or unrecognized values in the shorthand

<style>
  .masked {
    /* Error: too many values / unrecognized combination */
    mask: url(mask.svg) center center no-repeat contain;
  }
</style>
<div class="masked">Content</div>

Here, contain is a mask-size value but it must be separated from the position with a /. Without the slash, the validator sees an extra unrecognized value.

Correct: proper shorthand syntax with position and size

<style>
  .masked {
    mask: url(mask.svg) center / contain no-repeat;
  }
</style>
<div class="masked">Content</div>

The / separates mask-position (center) from mask-size (contain), just like in the background shorthand.

Correct: using longhand properties for clarity and compatibility

<style>
  .masked {
    width: 100px;
    height: 100px;
    background-color: #8cffb0;
    -webkit-mask-image: url(sun.svg);
    mask-image: url(sun.svg);
    mask-repeat: no-repeat;
    mask-position: center;
    mask-size: contain;
  }
</style>
<div class="masked">Content</div>

Using individual longhand properties avoids shorthand parsing issues entirely. Including the -webkit-mask-image prefix alongside the standard mask-image ensures broader browser support.

Incorrect: unrecognized value in the shorthand

<style>
  .masked {
    /* "luminance" is a mask-mode value but may not be recognized in the shorthand by all validators */
    mask: url(mask.png) luminance;
  }
</style>
<div class="masked">Content</div>

Correct: using the longhand for mask mode

<style>
  .masked {
    mask-image: url(mask.png);
    mask-mode: luminance;
  }
</style>
<div class="masked">Content</div>

When in doubt, splitting the mask shorthand into its individual longhand properties is the safest approach. It makes your intent explicit, avoids validation errors, and tends to have better cross-browser support.

The mask CSS shorthand property allows you to partially or fully hide portions of an element by applying a graphical mask. It is a shorthand for several sub-properties including mask-image, mask-mode, mask-repeat, mask-position, mask-clip, mask-origin, mask-size, and mask-composite. Because it’s a shorthand, each value you provide must correspond to one of these sub-properties’ accepted values. The validator triggers this error when it encounters a value that doesn’t fit any of them — for example, an arbitrary keyword, a misspelled function name, or an unsupported syntax.

Common causes of this error include:

• Arbitrary keywords — Using made-up names like star-shape or circle-mask that aren’t valid CSS values.
• Misspelled functions or keywords — Typos such as lnear-gradient() instead of linear-gradient(), or noen instead of none.
• Browser-prefixed values without the standard value — Using -webkit-mask syntax or values that don’t align with the standard mask property.
• Invalid shorthand combinations — Providing sub-property values in an order or combination the shorthand doesn’t accept.
• Missing url() wrapper — Referencing an image file path directly without wrapping it in the url() function.

This matters for standards compliance because browsers may silently ignore invalid mask values, resulting in the mask not being applied at all. Your design could look completely different than intended, and the failure may be hard to debug without validation.

Valid mask values

The mask property accepts one or more comma-separated mask layers. Each layer can include:

• none — No mask is applied.
• url() — A reference to an SVG mask element or an image file (e.g., url(mask.svg), url(mask.png)).
• CSS image functions — Such as linear-gradient(), radial-gradient(), conic-gradient(), image(), etc.
• Geometry box keywords (for mask-clip / mask-origin) — Such as content-box, padding-box, border-box, fill-box, stroke-box, view-box.
• Compositing keywords (for mask-composite) — Such as add, subtract, intersect, exclude.

Examples

Incorrect: arbitrary keyword as a mask value

<div style="mask: star-shape;">
  Masked Content
</div>

The value star-shape is not a recognized mask value and will be rejected by the validator.

Incorrect: missing url() function

<div style="mask: star.svg;">
  Masked Content
</div>

A bare file path is not valid. Image references must be wrapped in the url() function.

Correct: using url() to reference a mask image

<div style="mask: url(star.svg);">
  Masked Content
</div>

Correct: using none to explicitly disable masking

<div style="mask: none;">
  No Mask Applied
</div>

Correct: using a gradient as a mask

<div style="mask: linear-gradient(to right, transparent, black);">
  Fading Content
</div>

Correct: combining multiple shorthand values

<div style="mask: url(mask.png) no-repeat center / contain;">
  Masked Content
</div>

This sets the mask image, repeat behavior, position, and size in a single shorthand declaration.

Correct: multiple mask layers

<div style="mask: url(shape.svg) no-repeat, linear-gradient(to bottom, black, transparent);">
  Multi-layer Mask
</div>

When fixing this error, double-check your value against the CSS Masking specification on MDN. If you’re using vendor-prefixed versions like -webkit-mask, also ensure the standard mask property is present with valid values for forward compatibility.

The max-width property sets the maximum width an element can grow to, preventing the computed value of width from exceeding the specified limit. While many CSS sizing properties accept auto as a value (for example, width: auto and margin: auto are perfectly valid), the max-width property does not. This is a common mistake because developers often assume auto is universally accepted across similar properties.

When a browser encounters max-width: auto, it will typically ignore the invalid declaration and fall back to the default value of none. While the page may still render as expected in some browsers, relying on this behavior is unreliable and non-standard. Writing valid CSS ensures consistent rendering across all browsers and makes your stylesheets easier to maintain and debug.

If your intent is to remove a maximum width constraint (effectively making max-width have no effect), use none — this is the default value. If you want the element to size itself based on its content, use max-content, min-content, or fit-content. If you need to reset the property to its initial value, use initial (which resolves to none).

Valid values for max-width

The max-width property accepts the following types of values:

• none — No limit on the element’s width (the default).
• Length values — Such as 500px, 3.5em, 20rem, 80ch.
• Percentage values — Such as 75%, relative to the containing block’s width.
• Keyword values — max-content, min-content, fit-content, or fit-content(<length>).
• Global values — inherit, initial, revert, unset.

Examples

❌ Incorrect: using auto with max-width

<div style="max-width: auto;">
  This container has an invalid max-width value.
</div>

This triggers the validation error because auto is not a valid max-width value.

✅ Fixed: using none to remove the constraint

If you want no maximum width limit (the most likely intent when writing auto), use none:

<div style="max-width: none;">
  This container has no maximum width constraint.
</div>

✅ Fixed: using a specific length or percentage

If you want to cap the element’s width at a specific size:

<div style="max-width: 600px;">
  This container will not grow beyond 600 pixels.
</div>

<div style="max-width: 80%;">
  This container will not exceed 80% of its parent's width.
</div>

✅ Fixed: using intrinsic sizing keywords

If you want the element’s maximum width to be based on its content:

<div style="max-width: max-content;">
  This container's max width is determined by its content.
</div>

The min-height property sets the minimum height of an element. Unlike shorthand properties such as margin or padding, min-height accepts only a single value. Providing multiple space-separated values (e.g., min-height: 100px 200px) is invalid and will trigger this error.

This error commonly occurs for several reasons:

• Multiple values provided: min-height is not a shorthand and does not accept more than one value.
• Invalid units or typos: Using an unrecognized unit (e.g., 100pixels instead of 100px) or a misspelled keyword.
• Using unsupported CSS functions or syntax: Some newer CSS features like min-height: fit-content(200px) may not be recognized by the validator or may lack browser support.
• Confusing min-height with other properties: Accidentally using syntax meant for properties like grid-template-rows or minmax() expressions.
• Missing units on non-zero values: Writing min-height: 100 instead of min-height: 100px. Zero is the only numeric value that doesn’t require a unit.

According to the CSS specification, valid values for min-height include:

Fixing this issue ensures your CSS is standards-compliant and behaves predictably across browsers. Invalid min-height values will be ignored by browsers, which means your layout may not render as intended.

Examples

Incorrect: multiple values

<div style="min-height: 100px 200px;">Content</div>

min-height only accepts a single value. This is not a shorthand property.

Incorrect: missing unit

<div style="min-height: 100;">Content</div>

Non-zero numeric values must include a unit.

Incorrect: invalid keyword or typo

<div style="min-height: inheret;">Content</div>

The keyword inherit is misspelled.

Correct: single length value

<div style="min-height: 100px;">Content</div>

Correct: percentage value

<div style="min-height: 50%;">Content</div>

Correct: using calc() for computed values

<div style="min-height: calc(100vh - 80px);">Content</div>

Correct: using a keyword

<div style="min-height: min-content;">Content</div>

Correct: using auto

<div style="min-height: auto;">Content</div>

If you need to set both a minimum and maximum height on an element, use min-height and max-height as separate properties:

<div style="min-height: 100px; max-height: 400px;">Content</div>

These mso- prefixed properties are most commonly introduced when content is copied and pasted from Microsoft Word or other Office applications into an HTML editor. Microsoft Office generates heavily styled HTML with dozens of proprietary CSS properties designed to preserve the document’s formatting when rendered back in Office products. While browsers silently ignore these unknown properties, they clutter your markup, inflate file size, and violate web standards.

This is a problem for several reasons. First, these properties have no effect in any web browser — they are purely artifacts of Microsoft’s internal rendering engine. Second, they significantly bloat your HTML, sometimes doubling or tripling the size of the markup. Third, they make your code harder to read and maintain. Fourth, they can cause issues with automated tools, linters, and content management systems that expect valid CSS. Finally, in the context of HTML email development, while mso- properties are sometimes intentionally used to target Microsoft Outlook’s rendering engine, they should not appear in web pages intended for browsers.

How to Fix

1. Identify the source. Check if the content was pasted from Microsoft Word or another Office application. This is the most common origin.
2. Remove all mso- properties. Delete every CSS declaration that starts with mso-. They serve no purpose in a browser context.
3. Replace with standard CSS if needed. Some mso- properties have standard CSS equivalents. For example, mso-margin-top-alt can be replaced with margin-top, and mso-bidi-font-weight can be replaced with font-weight.
4. Use a paste-as-plain-text workflow. When copying from Word, paste as plain text first (Ctrl+Shift+V in many editors), then apply formatting using your own CSS.

Examples

❌ Incorrect: HTML with Microsoft Office properties

<p style="mso-spacerun: yes; mso-fareast-font-family: 'Times New Roman'; margin-bottom: .0001pt; mso-margin-bottom-alt: auto; mso-margin-top-alt: auto; mso-bidi-font-weight: bold; line-height: normal;">
  This text was pasted from Microsoft Word.
</p>

<style>
  .content {
    mso-fareast-font-family: "Calibri";
    mso-bidi-font-family: "Times New Roman";
    font-family: Arial, sans-serif;
    mso-line-height-rule: exactly;
    line-height: 1.5;
  }
</style>

✅ Correct: Cleaned-up HTML with only standard CSS

<p style="margin-bottom: 0; margin-top: auto; font-weight: bold; line-height: normal;">
  This text was pasted from Microsoft Word.
</p>

<style>
  .content {
    font-family: Arial, sans-serif;
    line-height: 1.5;
  }
</style>

Common mso- properties and their standard replacements

Many mso- properties (like mso-spacerun and mso-tab-count) control behaviors specific to Microsoft’s rendering engine and have no CSS equivalent at all. These can simply be deleted without any replacement. If your content originally came from Word, it’s often best to strip all formatting and restyle the content from scratch using your own clean CSS.

The padding-block shorthand property sets padding on the block-start and block-end sides of an element. In horizontal writing modes (like English), this corresponds to the top and bottom padding; in vertical writing modes, it maps to left and right. It’s the logical equivalent of combining padding-block-start and padding-block-end.

The reason auto is invalid here is that padding, by definition in the CSS specification, must resolve to a definite size. Margins can be auto because the browser uses that value in layout algorithms to distribute remaining space (e.g., centering a block element with margin-inline: auto). Padding, however, adds space inside an element’s border and has no such auto-distribution behavior defined in the spec. Attempting to use auto will cause the declaration to be ignored by browsers, meaning no padding is applied, which can lead to unexpected layout results.

This validation error often arises when developers confuse padding-block with margin-block, or when they copy centering patterns that work with margins and try to apply them to padding. If your intent was to center content, consider using margin-block: auto instead, or use Flexbox/Grid alignment properties.

How to Fix

Replace auto with a valid value:

• Length values: 0, 10px, 1em, 1.5rem, etc.
• Percentage values: 5%, 2% 1%, etc. (relative to the inline size of the containing block).
• Two values: padding-block: 20px 10px; sets padding-block-start to 20px and padding-block-end to 10px.
• CSS-wide keywords: inherit, initial, revert, revert-layer, or unset.

If you used auto to try to eliminate padding, use 0 instead. If you used it to try to center something, switch to margins or a layout method like Flexbox.

Examples

Incorrect: using auto as a padding-block value

<style>
  .box {
    padding-block: auto;
  }
</style>
<div class="box">This box has invalid padding.</div>

The browser will ignore the padding-block: auto declaration entirely, and the W3C validator will flag it as an error.

Correct: using length values

<style>
  .box {
    padding-block: 20px 10px;
  }
</style>
<div class="box">20px padding on block-start, 10px on block-end.</div>

Correct: using a single value for equal padding

<style>
  .box {
    padding-block: 1em;
  }
</style>
<div class="box">1em padding on both block-start and block-end.</div>

Correct: removing padding with zero

<style>
  .box {
    padding-block: 0;
  }
</style>
<div class="box">No block padding.</div>

If you intended to center: use margin-block instead

<style>
  .container {
    display: flex;
    flex-direction: column;
    height: 300px;
  }
  .centered {
    margin-block: auto;
  }
</style>
<div class="container">
  <div class="centered">This element is vertically centered using margin-block: auto.</div>
</div>

The margin-block: auto approach works inside flex or grid containers to distribute space evenly, achieving vertical centering. This is likely what you want if you originally reached for padding-block: auto.

The padding-bottom property defines the amount of space between an element’s content and its bottom border. Like all CSS length properties, it expects a length value — a number paired with a unit such as px, em, rem, %, vh, etc. The lone string px is just a unit identifier with no magnitude, so CSS parsers cannot interpret it as a meaningful measurement. This typically happens when a numeric value is accidentally deleted during editing, when a CSS preprocessor or template engine outputs an empty variable before the unit, or when code is manually written with a typo.

When the browser encounters an invalid value like padding-bottom: px, it discards the entire declaration and falls back to the default or inherited value. This can lead to unexpected layout shifts, where the spacing looks correct in one browser but breaks in another depending on how defaults are applied. Fixing these errors ensures consistent rendering across browsers and keeps your stylesheets standards-compliant.

How to fix it

1. Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
2. Use 0 without a unit if you want zero padding — writing padding-bottom: 0 is valid and preferred over 0px.
3. Check template variables — if you’re using a preprocessor like Sass or a templating engine, make sure the variable that generates the number is not empty or undefined.
4. Remove the declaration entirely if padding-bottom is not needed, rather than leaving a broken value in place.

Examples

Incorrect: unit without a number

<div style="padding-bottom: px;">Content</div>

The value px alone is not valid because there is no number specifying the amount of padding.

Correct: numeric value with a unit

<div style="padding-bottom: 10px;">Content</div>

Correct: zero padding (no unit needed)

<div style="padding-bottom: 0;">Content</div>

Incorrect in an external stylesheet

.card {
  padding-bottom: px;
}

Correct in an external stylesheet

.card {
  padding-bottom: 16px;
}

Common preprocessor pitfall

In Sass or similar tools, this issue often arises from an empty or undefined variable:

$spacing: null;

.card {
  padding-bottom: #{$spacing}px; // Outputs "padding-bottom: px;" if $spacing is empty
}

The fix is to ensure the variable holds a valid number, or provide a fallback:

$spacing: 16;

.card {
  padding-bottom: #{$spacing}px; // Outputs "padding-bottom: 16px;"
}

Even better, include the unit in the variable itself to avoid concatenation issues:

$spacing: 16px;

.card {
  padding-bottom: $spacing;
}

The padding-left property accepts a valid CSS length value, a percentage, or the keyword 0. A CSS length is always composed of two parts: a number and a unit (e.g., 10px, 2em, 1.5rem). Writing just px with no number is syntactically invalid — it’s a bare unit with no magnitude, so the browser cannot determine what spacing to apply. This commonly occurs due to a typo, a missing variable in a template or preprocessor, or accidentally deleting the numeric portion during editing.

When the validator encounters this in a style attribute, it flags the value as invalid CSS. While most browsers will simply ignore the malformed declaration and fall back to the default padding, relying on this error-recovery behavior leads to unpredictable layouts. Fixing the issue ensures your styles are applied consistently across all browsers and that your markup passes validation.

How to fix it

1. Add a numeric value before the unit: change px to something like 10px, 1em, or 5%.
2. If you want zero padding, use 0 — no unit is needed (though 0px is also valid).
3. Check template variables and preprocessors. If you’re using a system like PHP, JavaScript templating, or a CSS preprocessor (Sass, Less), make sure the variable that should supply the number isn’t empty or undefined. For example, padding-left: <?= $indent ?>px; will produce padding-left: px; if $indent is empty.

Examples

Incorrect: bare unit with no number

<div style="padding-left: px;">Content</div>

The value px has no numeric component, so it is not a valid length.

Correct: numeric value before the unit

<div style="padding-left: 10px;">Content</div>

Correct: zero padding (no unit required)

<div style="padding-left: 0;">Content</div>

Incorrect: empty variable producing a bare unit

This is a common source of the bug in templated or dynamically generated HTML:

<!-- If the variable is empty, this renders as "padding-left: px;" -->

<div style="padding-left: px;">Content</div>

Correct: ensuring a fallback value

When generating styles dynamically, always provide a sensible default so the output is valid even if the variable is missing:

<div style="padding-left: 16px;">Content</div>

Using an external stylesheet

The same rule applies in external or embedded CSS. The incorrect version:

.sidebar {
  padding-left: px;
}

The corrected version with a proper numeric value:

.sidebar {
  padding-left: 20px;
}

Other valid padding-left values

Any valid CSS length or percentage works:

<div style="padding-left: 2em;">Em-based padding</div>
<div style="padding-left: 1.5rem;">Rem-based padding</div>
<div style="padding-left: 5%;">Percentage-based padding</div>

The padding shorthand property sets the padding area on all four sides of an element. It accepts one to four values, each of which must be a <length> (e.g., 10px, 1em), a <percentage>, or 0. Unlike some other CSS properties such as border, outline, or max-width, the padding property has no none keyword in its value syntax.

This is a common mistake because several CSS properties do accept none — for example, border: none, text-decoration: none, and display: none. It’s natural to assume padding: none would work the same way, but the CSS specification simply doesn’t define it for padding. When a browser encounters an invalid value, it ignores the declaration entirely, which means your intended styling won’t be applied and the element may retain its default or inherited padding. This can lead to unexpected layout issues that are difficult to debug.

The same rule applies to the margin property — margin: none is also invalid. Use margin: 0 instead.

How to Fix It

Replace none with 0. You don’t need to include a unit when the value is zero, so padding: 0 is perfectly valid and is the idiomatic way to express “no padding.” You can also use 0 for individual padding properties like padding-top, padding-right, padding-bottom, and padding-left.

If you only want to remove padding on specific sides, target those sides individually rather than using the shorthand.

Examples

❌ Incorrect: Using none with padding

.card {
  padding: none;
}

The validator will report: CSS: “padding”: “none” is not a “padding” value. The browser will ignore this declaration.

✅ Correct: Using 0 to remove padding

.card {
  padding: 0;
}

✅ Correct: Removing padding on specific sides

.card {
  padding-top: 0;
  padding-bottom: 0;
}

❌ Incorrect: Using none in inline styles

<div style="padding: none;">Content</div>

✅ Correct: Using 0 in inline styles

<div style="padding: 0;">Content</div>

✅ Correct: Using valid padding values

/* Single value — applies to all four sides */
.card {
  padding: 16px;
}

/* Two values — vertical | horizontal */
.card {
  padding: 10px 20px;
}

/* Four values — top | right | bottom | left */
.card {
  padding: 10px 20px 15px 5px;
}

/* Zero on top/bottom, 1em on left/right */
.card {
  padding: 0 1em;
}

The padding property accepts one or more length values, percentages, or the keyword 0. A valid length value always consists of a number immediately followed by a unit identifier, such as 10px, 1.5em, or 2rem. Writing just px without a preceding number is meaningless to the CSS parser — it’s like saying “pixels” without specifying how many. The browser will discard the invalid declaration entirely, which means the element will fall back to its default or inherited padding, potentially breaking your layout in unexpected ways.

This error commonly occurs due to:

• Typos or accidental deletion — the numeric part of the value was inadvertently removed during editing.
• Templating or build tool issues — a dynamic value (e.g., from a variable or CMS field) resolved to an empty string, leaving only the px suffix behind.
• Copy-paste mistakes — copying a snippet and forgetting to update the placeholder value.

Because the W3C validator flags this in inline style attributes, it means invalid CSS is embedded directly in your HTML. Fixing it improves standards compliance and ensures consistent rendering across browsers.

How to Fix

1. Add a numeric value before the unit: change px to something like 10px, 1em, or 5%.
2. Use 0 without a unit if you want zero padding — writing padding: 0; is valid and preferred over padding: 0px;.
3. Check dynamic values — if the number comes from a variable or template expression, make sure it outputs a valid number and isn’t empty.

Examples

Incorrect: Unit Without a Number

<div style="padding: px;">Content</div>

The validator reports that px is not a valid padding value because no number precedes the unit.

Correct: Numeric Value With Unit

<div style="padding: 10px;">Content</div>

Correct: Zero Padding (No Unit Needed)

<div style="padding: 0;">Content</div>

When the value is 0, no unit is required since zero pixels, zero ems, and zero percent are all identical.

Correct: Multiple Padding Values

<div style="padding: 8px 16px;">Content</div>

This sets 8px of vertical padding and 16px of horizontal padding — both are valid length values.

Incorrect in External CSS

The same problem can appear in a stylesheet linked from your HTML:

.card {
  padding: px;
}

Fixed in External CSS

.card {
  padding: 12px;
}

Watch for Template-Generated Values

If you use a templating system, double-check that the numeric portion actually renders. For example, a template like this could produce the error if spacing is empty:

<!-- If spacing is empty, this becomes "padding: px;" -->

<div style="padding: {{ spacing }}px;">Content</div>

Make sure the variable always resolves to a valid number, or provide a fallback value.

The padding-right property defines the space between an element’s content and its right border. According to the CSS Box Model specification, padding represents internal space within an element, and conceptually, negative internal space doesn’t make sense — you can’t have less than zero space between content and its border. This rule applies equally to all padding properties: padding-top, padding-right, padding-bottom, padding-left, and the padding shorthand.

Browsers will typically ignore or discard a negative padding value, meaning your intended layout adjustment won’t take effect. Beyond simply being invalid CSS, this can lead to inconsistent rendering across browsers and unexpected layout behavior. Relying on invalid values makes your stylesheets fragile and harder to maintain.

If your goal is to pull an element closer to its neighbor or create an overlapping effect, margin-right is the appropriate property to use. Unlike padding, margins are explicitly allowed to have negative values. Negative margins reduce the space between elements or even cause them to overlap, which is often the actual intent behind a negative padding attempt.

How to Fix

1. Set the value to 0 or a positive number. If you simply want no padding, use 0. If you need some spacing, use a positive value.
2. Use margin-right for negative spacing. If you need to reduce external space or create overlap, switch to a negative margin instead.
3. Re-evaluate your layout approach. In some cases, using transform: translateX(), Flexbox gap, or Grid layout may achieve the desired result more cleanly than negative values on any property.

Examples

Incorrect: negative padding value

<style>
  .sidebar {
    padding-right: -10px;
  }
</style>
<div class="sidebar">
  <p>Sidebar content</p>
</div>

This triggers the validator error because -10px is not a valid value for padding-right.

Fixed: using zero or a positive value

<style>
  .sidebar {
    padding-right: 0;
  }
</style>
<div class="sidebar">
  <p>Sidebar content</p>
</div>

Fixed: using a negative margin instead

If the intent was to reduce external spacing on the right side, use margin-right:

<style>
  .sidebar {
    padding-right: 0;
    margin-right: -10px;
  }
</style>
<div class="sidebar">
  <p>Sidebar content</p>
</div>

Fixed: using transform for visual offset

If the goal is to visually shift the element without affecting document flow, transform is another option:

<style>
  .sidebar {
    padding-right: 0;
    transform: translateX(10px);
  }
</style>
<div class="sidebar">
  <p>Sidebar content</p>
</div>

Quick reference: padding vs. margin

Choose the property that matches your layout intent, and remember that all four padding directions — padding-top, padding-right, padding-bottom, and padding-left — follow the same non-negative rule.

The padding-right property defines the amount of space between an element’s content and its right border. Like all CSS length properties, it expects either a valid length value (a number paired with a unit like px, em, rem, %, vw, etc.), the keyword 0 (which needs no unit), or the keyword inherit/initial/unset. A bare unit such as px with no number is meaningless — it doesn’t tell the browser how much padding to apply.

This error typically occurs due to a typo, a templating issue where a variable failed to render, or accidental deletion of the numeric portion of the value. For example, a template like padding-right: {{ value }}px; might produce padding-right: px; if value is empty or undefined.

When the browser encounters an invalid value like px, it discards the entire declaration and falls back to the default or inherited value for padding-right. This can lead to unexpected layout differences across browsers and makes your intentions unclear to other developers. Fixing these validation errors also helps maintain clean, predictable stylesheets.

How to Fix

1. Add the missing number before the unit: change px to a specific value like 10px.
2. Use 0 without a unit if you want no padding: padding-right: 0; is valid and preferred over padding-right: 0px;.
3. Check template variables and dynamic style generation to ensure numeric values are always output correctly.

Examples

Incorrect: bare unit with no number

<div style="padding-right: px;">Content</div>

The value px is not valid because it lacks a numeric component.

Correct: numeric value with unit

<div style="padding-right: 10px;">Content</div>

Correct: zero padding (no unit needed)

<div style="padding-right: 0;">Content</div>

Correct: using other valid units

<div style="padding-right: 2em;">Content</div>

<div style="padding-right: 5%;">Content</div>

Incorrect in an external stylesheet

.sidebar {
  padding-right: px;
}

Fixed in an external stylesheet

.sidebar {
  padding-right: 16px;
}

Guarding against empty values in templates

If you generate CSS dynamically, make sure the numeric value is always present. For instance, provide a fallback:

.sidebar {
  padding-right: 16px; /* safe default */
}

Rather than relying on a template that might produce an empty value, consider setting defaults in your CSS and only overriding with inline styles when you’re certain the value is valid.

The W3C validator reports this error when it encounters padding-top: px; — a unit with no numeric component. In CSS, length values are composed of two parts: a number and a unit identifier (e.g., px, em, rem, %, vh). The unit alone is meaningless without a number to quantify it. This typically happens due to a typo, a preprocessor variable that resolved to an empty value, or accidentally deleting the number during editing.

This matters for several reasons. Browsers will discard the invalid declaration entirely, meaning padding-top will fall back to its default or inherited value — which may not be what you intended. This can cause unpredictable layout differences across browsers. Additionally, invalid CSS can interfere with parsing of subsequent declarations in the same rule block, potentially causing other styles to be ignored as well.

To fix this issue:

1. Add a numeric value before the unit: change px to something like 10px, 1.5em, or 20%.
2. Use 0 without a unit if you want zero padding: padding-top: 0; is valid and preferred over padding-top: 0px;.
3. Check preprocessor variables (Sass, Less, etc.) to make sure they resolve to complete values, not just units.
4. Remove the declaration entirely if padding-top doesn’t need to be set.

Examples

Incorrect: unit without a number

<div style="padding-top: px;">Content</div>

The value px is not a valid padding-top value because it lacks a numeric component.

Correct: number with a unit

<div style="padding-top: 10px;">Content</div>

Correct: zero padding (no unit needed)

<div style="padding-top: 0;">Content</div>

Incorrect in an external stylesheet

.header {
  padding-top: px;
}

Correct in an external stylesheet

.header {
  padding-top: 16px;
}

Common preprocessor pitfall

If you use a CSS preprocessor like Sass, watch out for variables that might be empty or undefined:

/* If $spacing somehow resolves to empty, this produces "padding-top: px;" */
.card {
  padding-top: $spacing + px;
}

/* Safer approach — define the variable with the full value */
.card {
  padding-top: $spacing;  /* where $spacing: 16px; */
}

Any valid CSS length value will work for padding-top, including px, em, rem, %, vw, vh, ch, and others — as long as a number precedes the unit. The only length value that doesn’t require a unit is 0.