HTML Guides

CSS: “align-items”: X is not a “align-items” value.

CSS: “aspect-ratio”: X is not a “aspect-ratio” value.

The aspect-ratio CSS property defines the preferred width-to-height ratio of an element's box. Browsers use this ratio when calculating auto sizes and performing other layout functions, adjusting the element's dimensions to maintain the specified proportion even as the parent container or viewport changes size.

The ratio is expressed as <width> / <height>. If the slash and height portion are omitted, height defaults to 1. So aspect-ratio: 2 is equivalent to aspect-ratio: 2 / 1. The property also accepts the auto keyword, which tells the element to use its intrinsic aspect ratio (if it has one), and a combined form like auto 3 / 4, which prefers the intrinsic ratio but falls back to the specified one.

This validation error typically occurs for several reasons:

Using invalid separators or syntax, such as a colon (:) instead of a slash (/), e.g., aspect-ratio: 16:9.
Providing units, such as aspect-ratio: 16px / 9px. The values must be unitless positive numbers.
Using zero or negative numbers, which are not valid. Both parts of the ratio must be positive (> 0).
Providing a string or unrecognized keyword, such as aspect-ratio: wide or aspect-ratio: "16/9".
Missing spaces around the slash, though this is less common — 16/9 may work in browsers but the canonical form uses spaces: 16 / 9.
Using the property in inline style attributes validated against an older CSS level where aspect-ratio wasn't yet recognized by the validator.

Getting this value right matters for layout consistency across browsers. An invalid value will be ignored entirely by the browser, meaning the element won't maintain any aspect ratio, potentially breaking your design. It's especially important for responsive images, video containers, and card layouts where maintaining proportions is critical.

Examples

Incorrect: using a colon as the separator

<divstyle="aspect-ratio:16:9;width:100%;"></div>

The colon syntax (common in video specifications) is not valid CSS. The validator will reject 16:9 as an aspect-ratio value.

Incorrect: using units in the ratio

<divstyle="aspect-ratio:16px/9px;width:100%;"></div>

The ratio values must be unitless numbers. Adding px or any other unit makes the value invalid.

Incorrect: using zero in the ratio

<divstyle="aspect-ratio:0/1;width:100%;"></div>

Both numbers in the ratio must be strictly positive. Zero is not allowed.

Correct: standard ratio with a slash

<divstyle="aspect-ratio:16/9;width:100%;"></div>

Correct: single number (height defaults to 1)

<divstyle="aspect-ratio:2;width:100%;"></div>

This is equivalent to aspect-ratio: 2 / 1.

Correct: square ratio

<divstyle="aspect-ratio:1/1;width:100%;"></div>

Correct: using the `auto` keyword

<imgsrc="photo.jpg"alt="A landscape photo"style="aspect-ratio: auto;width:100%;">

The element uses its intrinsic aspect ratio if available.

Correct: combining `auto` with a fallback ratio

<imgsrc="photo.jpg"alt="A landscape photo"style="aspect-ratio: auto 4/3;width:100%;">

The browser prefers the image's intrinsic ratio, but if it hasn't loaded yet or has no intrinsic ratio, it falls back to 4 / 3. This is useful for preventing layout shift while images load.

Correct: using global CSS values

<divstyle="aspect-ratio: inherit;width:100%;"></div>

Global values like inherit, initial, unset, revert, and revert-layer are also valid.

CSS: “background-blend-mode”: X is not a “background-blend-mode” value.

The background-blend-mode property controls how an element's background layers — including background images and background colors — blend with each other. Each value must be a valid blend mode keyword as defined in the CSS Compositing and Blending specification. The W3C validator flags this error when it encounters a value that doesn't match any recognized keyword, which can happen due to typos, made-up values, or confusion with similar properties like mix-blend-mode.

While browsers typically ignore unrecognized CSS values and fall back to the default (normal), relying on this behavior is risky. It means the blending effect you intended simply won't appear, and the silent failure can be hard to debug. Fixing validation errors ensures your styles work as intended across all browsers.

The complete list of valid values for background-blend-mode is:

normal (default)
multiply
screen
overlay
darken
lighten
color-dodge
color-burn
hard-light
soft-light
difference
exclusion
hue
saturation
color
luminosity

You can also specify multiple comma-separated values when an element has multiple background layers. Each value corresponds to a background layer in the same order.

Examples

Invalid values

These examples will trigger the validation error:

/* Typo: "multipley" is not a valid keyword */

.hero{

background-blend-mode: multipley;

}

/* "blend" is not a recognized value */

.banner{

background-blend-mode: blend;

}

/* Numeric values are not accepted */

.card{

background-blend-mode:50%;

}

Corrected values

/* Fixed: correct spelling */

.hero{

background-blend-mode: multiply;

}

/* Fixed: use a valid blend mode keyword */

.banner{

background-blend-mode: overlay;

}

/* Fixed: use a keyword instead of a numeric value */

.card{

background-blend-mode: soft-light;

}

Multiple background layers

When you have multiple background images, provide a comma-separated list of valid blend modes:

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Background Blend Mode Example</title>

<style>

.blended{

width:300px;

height:200px;

background-color: teal;

background-image:url("pattern.png"),url("photo.jpg");

background-blend-mode: screen, multiply;

}

</style>

</head>

<body>

<divclass="blended">Blended background layers</div>

</body>

</html>

In this example, screen applies to the first background image layer and multiply applies to the second. Both are valid keywords, so no validation error is produced.

CSS: “background-color”: Lexical error at line L, column C. Encountered: ";" (59), after : "#".

CSS: “background-color”: “X” is not a “background-color” value.

The background-color property accepts a specific set of color value types defined in the CSS Color specification. When you provide something that doesn't match any of these types — like a plain number, a misspelled keyword, or a malformed hex code — the validator flags it as an invalid value.

Common mistakes that trigger this error include:

Bare numbers like 0 or 255 — numbers alone aren't colors, even if you intended black or white.
Misspelled color keywords like grren instead of green, or trasparent instead of transparent.
Malformed hex codes like #GGG, #12345, or missing the # prefix entirely.
Incorrect function syntax like rgb(255 0 0 0.5) when mixing legacy comma syntax with modern space syntax improperly, or using rgba with only three arguments.
Invalid units or strings like background-color: 10px or background-color: "red" (color values should not be quoted).

While browsers are generally forgiving and will simply ignore an invalid background-color declaration, this means your intended styling silently fails. The element falls back to its inherited or default background, which can cause visual bugs, poor contrast, or accessibility issues that are hard to track down. Validating your CSS catches these problems early.

Valid color formats

The background-color property accepts these value types:

Named keywords: red, blue, transparent, currentcolor, etc.
Hex notation: #rgb, #rrggbb, #rgba, #rrggbbaa
RGB/RGBA: rgb(255, 0, 0) or rgb(255 0 0 / 0.5)
HSL/HSLA: hsl(120, 100%, 50%) or hsl(120 100% 50% / 0.5)
The keyword inherit, initial, unset, or revert

Examples

Invalid: bare number as a color

A plain number like 0 is not a valid color value, even though black could be represented as all zeros in RGB.

<style>

.banner{

background-color:0;

}

</style>

Invalid: misspelled keyword

<style>

.banner{

background-color: trasparent;

}

</style>

Invalid: quoted string

Color values must not be wrapped in quotes.

<style>

.banner{

background-color:"red";

}

</style>

Invalid: malformed hex code

Hex codes must be 3, 4, 6, or 8 characters after the #.

<style>

.banner{

background-color:#12345;

}

</style>

Fixed: using a named color keyword

<style>

.banner{

background-color: black;

}

</style>

Fixed: using a hex color

<style>

.banner{

background-color:#000000;

}

</style>

Fixed: using `rgb()` notation

<style>

.banner{

background-color:rgb(0,0,0);

}

</style>

Fixed: using `rgba()` for semi-transparency

<style>

.banner{

background-color:rgba(0,0,0,0.5);

}

</style>

Fixed: using `hsl()` notation

<style>

.banner{

background-color:hsl(210,50%,40%);

}

</style>

Fixed: using `transparent`

<style>

.banner{

background-color: transparent;

}

</style>

CSS: “background”: “from” is not a valid color 3 or 6 hexadecimals numbers.

The background CSS property accepts a variety of value types: named colors (red, blue), hexadecimal codes (#fff, #ff0000), color functions (rgb(), hsl(), rgba()), gradient functions (linear-gradient(), radial-gradient()), image URLs, and CSS keywords like none, transparent, or inherit. The word from is not among these valid values.

Why this happens

This error most commonly appears in one of these scenarios:

Legacy WebKit gradient syntax. Older versions of Safari and Chrome used a proprietary syntax: -webkit-gradient(linear, left top, right top, from(#fff), to(#000)). The from() and to() functions are part of this deprecated, non-standard format. If this syntax is used without the -webkit- prefix—or if the validator encounters it—the word from gets flagged as an invalid color value.
Incorrectly written gradient shorthand. Some developers unfamiliar with the CSS gradient specification write something resembling natural language, like background: from #fff to #000, which has no meaning in CSS.
CSS from keyword in relative color syntax. CSS Color Level 5 introduces relative color syntax using the from keyword (e.g., rgb(from red r g b / 50%)). This is a newer feature that may not yet be recognized by the W3C CSS validator, which can lag behind the latest specifications. If you're using this syntax intentionally, the error may be a false positive from the validator, but be aware that browser support may still be limited.

Why it matters

Invalid CSS values are silently ignored by browsers, meaning your intended background styling won't be applied. The element will fall back to its default or inherited background, which can result in broken layouts, missing visual cues, or poor contrast that harms readability and accessibility. Using standard, valid CSS ensures consistent rendering across all browsers.

How to fix it

Replace legacy -webkit-gradient() syntax with the standard linear-gradient() or radial-gradient() functions.
Use valid color formats for solid backgrounds: hex codes, named colors, or color functions.
If using relative color syntax (from keyword in CSS Color Level 5), understand that the validator may not yet support it. Consider adding a fallback value for broader compatibility.

Examples

Incorrect: legacy WebKit gradient syntax

The from() and to() functions in -webkit-gradient() are non-standard and will trigger this error if used as a background value:

<style>

.banner{

/* Non-standard syntax; "from" is not a valid CSS value */

background:-webkit-gradient(linear, left top, right top,from(#fff),to(#000));

}

</style>

<divclass="banner">Legacy gradient</div>

Incorrect: made-up gradient shorthand

Writing gradient-like syntax without a proper CSS function is invalid:

<style>

.banner{

/* "from" and "to" are not valid CSS keywords here */

background: from #fff to #000;

}

</style>

<divclass="banner">Invalid gradient</div>

Correct: standard linear gradient

Use linear-gradient() with a direction and comma-separated color stops:

<style>

.banner{

background:linear-gradient(to right,#fff,#000);

}

</style>

<divclass="banner">Standard gradient</div>

Correct: solid color background

For a simple solid color, use any valid CSS color value:

<style>

.banner{

background:#fff;

}

</style>

<divclass="banner">White background</div>

Correct: gradient with a fallback for older browsers

When using gradients, it's good practice to provide a solid color fallback:

<style>

.banner{

background:#fff;

background:linear-gradient(to bottom,#ffffff,#cccccc);

}

</style>

<divclass="banner">Gradient with fallback</div>

Correct: relative color syntax with a fallback

If you intentionally use CSS Color Level 5 relative color syntax and the validator flags from, provide a fallback and be aware of current browser support:

<style>

.banner{

background:rgb(255,0,0);

background:rgb(from red r g b /50%);

}

</style>

<divclass="banner">Relative color with fallback</div>

Always verify that your background values use standard CSS syntax. When in doubt, test your styles in the W3C CSS Validator and check browser support on Can I Use.

CSS: “background-image”: Parse Error.

When the CSS parser encounters a background-image value it cannot understand, it flags a parse error. This doesn't necessarily mean the browser won't render your styles — browsers are often more forgiving than validators — but it does indicate that your CSS doesn't conform to the specification. Invalid CSS can lead to unpredictable rendering across different browsers, makes your code harder to maintain, and may cause styles to silently fail in certain environments.

Common causes of this error include:

Missing the url() function around image paths.
Unquoted or improperly quoted URLs containing special characters like spaces or parentheses.
Typos in CSS function names (e.g., lnear-gradient instead of linear-gradient).
Using vendor-prefixed values (e.g., -webkit-linear-gradient) in contexts where the validator expects standard CSS.
Invalid gradient syntax, such as missing color stops, incorrect angle units, or malformed function arguments.
Using CSS custom properties (variables) or newer syntax in a style attribute, which the validator's CSS parser may not fully support.

To fix this, review the exact background-image declaration the validator is pointing to. Make sure all URLs are wrapped in url(), all gradients use correct function names and valid arguments, and all strings are properly quoted and closed.

Examples

Missing `url()` function

A bare file path without the url() wrapper is invalid:

<divstyle="background-image: /images/hero.jpg;"></div>

Wrap the path in url():

<divstyle="background-image:url('/images/hero.jpg');"></div>

Typo in gradient function name

<divstyle="background-image:lnear-gradient(to right, red, blue);"></div>

<divstyle="background-image:linear-gradient(to right, red, blue);"></div>

Invalid gradient syntax

Missing color stops or using incorrect angle notation causes parse errors:

<divstyle="background-image:linear-gradient(45, red);"></div>

Angles need a unit (like deg), and gradients need at least two color stops:

<divstyle="background-image:linear-gradient(45deg, red, blue);"></div>

Unescaped special characters in URL

File paths with spaces or parentheses need to be quoted:

<divstyle="background-image:url(/images/my hero image.jpg);"></div>

<divstyle="background-image:url('/images/my hero image.jpg');"></div>

Vendor-prefixed values

Using non-standard prefixed syntax can trigger a parse error in the validator:

<divstyle="background-image:-webkit-linear-gradient(left, red, blue);"></div>

Use the standard, unprefixed syntax instead. Modern browsers no longer need the prefix for gradients:

<divstyle="background-image:linear-gradient(to right, red, blue);"></div>

Multiple backgrounds with incorrect separator

Multiple background images must be separated by commas, not semicolons or spaces:

<divstyle="background-image:url('a.png')url('b.png');"></div>

<divstyle="background-image:url('a.png'),url('b.png');"></div>

Moving styles to an external stylesheet

If the validator struggles with complex background-image values in inline style attributes, consider moving the CSS to a <style> block or external stylesheet, where the validator's CSS parser handles them more reliably:

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Background Image Example</title>

<style>

.hero{

background-image:url('hero.jpg');

background-size: cover;

}

</style>

</head>

<body>

<divclass="hero"></div>

</body>

</html>

CSS: “background-image”: X is not a “background-image” value.

The background-image CSS property accepts a specific set of value types defined by the CSS specification. The most common are none (the default, meaning no image), the url() function pointing to an image file, and gradient functions like linear-gradient() or radial-gradient(). When the validator encounters a value that doesn't match any of these patterns, it flags the error.

This issue often appears in inline style attributes within HTML, which is where the W3C HTML Validator checks your CSS. Common mistakes include providing a bare filename without url(), forgetting parentheses or quotes, using incorrect gradient syntax, or introducing typos in CSS function names.

Fixing this matters for several reasons. Browsers may silently ignore an invalid background-image declaration entirely, meaning your intended background simply won't appear. This leads to broken visual designs that can be difficult to debug. Additionally, invalid CSS can cause parsing errors that may affect subsequent declarations in the same rule block.

How to fix it

Wrap image paths in url() — A bare filename like background-image: photo.jpg is invalid. It must be background-image: url("photo.jpg").
Use proper quoting — While quotes inside url() are technically optional for simple paths, always use them for paths containing spaces, parentheses, or special characters. Single or double quotes both work.
Check gradient syntax — If using gradients, ensure the function name is correct (e.g., linear-gradient, not linear-gradiant) and the arguments follow valid syntax.
Use recognized keywords — The only non-function keyword accepted is none. Values like transparent, auto, or arbitrary strings are not valid for this property.

Examples

Incorrect: bare filename without `url()`

<divstyle="background-image: hero.jpg;">

Content here

</div>

Incorrect: misspelled function name

<divstyle="background-image:urls('hero.jpg');">

Content here

</div>

Incorrect: missing parentheses in `url`

<divstyle="background-image: url 'hero.jpg';">

Content here

</div>

Incorrect: invalid keyword

<divstyle="background-image: transparent;">

Content here

</div>

Correct: using `url()` with a file path

<divstyle="background-image:url('hero.jpg');">

Content here

</div>

Correct: using `none` to explicitly set no background image

<divstyle="background-image: none;">

Content here

</div>

Correct: using a gradient function

<divstyle="background-image:linear-gradient(to right,#ff7e5f,#feb47b);">

Content here

</div>

Correct: multiple background images

<divstyle="background-image:url('overlay.png'),linear-gradient(to bottom,#000,#333);">

Content here

</div>

Correct: using a `<style>` block

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Background Image Example</title>

<style>

.banner{

background-image:url("banner.png");

background-size: cover;

background-repeat: no-repeat;

}

</style>

</head>

<body>

<divclass="banner">Welcome</div>

</body>

</html>

Always wrap image paths in the url() function, double-check function names for typos, and use quotes around paths that contain special characters. When in doubt, move your styles out of inline style attributes and into a <style> block or external stylesheet, which makes debugging CSS issues much easier.

CSS: “background-image”: X is not a “color” value.

CSS: “background”: The first argument to the “linear-gradient” function should be “to top”, not “top”.

The linear-gradient() function went through several syntax revisions during CSS standardization. Early drafts and vendor-prefixed implementations (like -webkit-linear-gradient()) used bare direction keywords such as top, bottom left, etc., where the keyword indicated the starting point of the gradient. The final standard, defined in the CSS Images Module Level 3 and Level 4 specifications, changed this so that direction keywords use the to prefix and indicate the ending point of the gradient. For example, the old linear-gradient(top, #fff, #000) meant "start at the top and go to the bottom," while the correct modern equivalent is linear-gradient(to bottom, #fff, #000).

This matters because the old syntax without to is not valid CSS per the current specification. While some browsers may still interpret the legacy syntax for backward compatibility, relying on it is risky — behavior can vary across browsers, and it will trigger validation errors. Using standard-compliant CSS ensures consistent rendering and forward compatibility.

How to fix it

Replace the bare direction keyword with the correct to syntax. Note that the direction meaning is inverted: the old syntax specified where the gradient starts, while the new syntax specifies where it goes to.

Here's a quick mapping from old to new syntax:

Old (invalid)	New (valid)	Angle equivalent
`top`	`to bottom`	`180deg`
`bottom`	`to top`	`0deg`
`left`	`to right`	`90deg`
`right`	`to left`	`270deg`
`top left`	`to bottom right`	N/A (use `to` syntax)

Important: Notice that top in the old syntax means "start at top, go to bottom." So the modern equivalent is to bottom, not to top. If the validator message says the argument should be to top, it means you wrote top — but be sure you understand which direction your gradient should actually go before blindly replacing it. If you truly want the gradient to go toward the top, use to top. If you want it to go from the top downward, use to bottom.

If you don't specify a direction at all, linear-gradient() defaults to to bottom (top-to-bottom), which is often what you want.

Examples

Invalid: bare direction keyword

<divstyle="background:linear-gradient(top,#ffffff,#000000);">

Content

</div>

The bare keyword top is not valid in the standard linear-gradient() syntax and will trigger the validator error.

Fixed: using the `to` keyword

<divstyle="background:linear-gradient(to bottom,#ffffff,#000000);">

Content

</div>

Since the old top meant "start at the top," the equivalent standard syntax is to bottom.

Fixed: using an angle

<divstyle="background:linear-gradient(180deg,#ffffff,#000000);">

Content

</div>

An angle of 180deg produces the same top-to-bottom gradient.

Full document example

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Gradient Example</title>

<style>

.box{

width:200px;

height:100px;

/* Valid: direction keyword with "to" */

background:linear-gradient(to top,#ffffff,#000000);

}

.box-angle{

width:200px;

height:100px;

/* Valid: angle equivalent of "to top" */

background:linear-gradient(0deg,#ffffff,#000000);

}

.box-default{

width:200px;

height:100px;

/* Valid: no direction specified, defaults to "to bottom" */

background:linear-gradient(#ffffff,#000000);

}

</style>

</head>

<body>

<divclass="box"></div>

<divclass="box-angle"></div>

<divclass="box-default"></div>

</body>

</html>

All three approaches are valid. Choose whichever is clearest for your use case — the to keyword syntax is generally the most readable, while angles offer more precision for diagonal or non-cardinal directions.

CSS: “background”: X is not a “background-color” value.

The background CSS property is a shorthand that can accept values for background-color, background-image, background-position, background-size, background-repeat, background-origin, background-clip, and background-attachment. When the validator encounters an unrecognized value, it tries to match it against individual sub-properties like background-color. If the value doesn't match any of them, you'll see this error.

Common causes include typos in color names (e.g., bleu instead of blue), malformed hex codes (e.g., #gggggg or a missing #), incorrect function syntax (e.g., rgb(255 0 0 with a missing parenthesis), or using values that simply don't exist in CSS. This error can also appear when a CSS custom property (variable) is used in inline styles and the validator can't resolve it, or when a browser-specific value is used that isn't part of the CSS specification.

Fixing this issue ensures your styles render predictably across browsers. While browsers are often forgiving and may ignore invalid declarations silently, relying on that behavior can lead to inconsistent rendering. Standards-compliant CSS is easier to maintain and debug.

How to Fix

Check for typos in color names, hex codes, or function syntax.
Verify the value format — hex colors need a # prefix, rgb() and rgba() need proper comma-separated or space-separated values with closing parentheses.
Use background-color instead of the shorthand background if you only intend to set a color. This makes your intent clearer and reduces the chance of conflicting shorthand values.
Remove vendor-prefixed or non-standard values that the validator doesn't recognize.

Examples

Incorrect — Typo in color name

<divstyle="background: aquaa;">Content</div>

aquaa is not a valid CSS color name, so the validator rejects it.

Correct — Valid color name

<divstyle="background: aqua;">Content</div>

Incorrect — Malformed hex code

<divstyle="background:#xyz123;">Content</div>

Hex color codes only allow characters 0–9 and a–f.

Correct — Valid hex code

<divstyle="background:#00a123;">Content</div>

Incorrect — Missing hash symbol

<divstyle="background: ff0000;">Content</div>

Without the #, the validator interprets ff0000 as an unknown keyword.

Correct — Hex code with hash

<divstyle="background:#ff0000;">Content</div>

Incorrect — Broken `rgb()` syntax

<divstyle="background:rgb(255,0,300);">Content</div>

RGB channel values must be between 0 and 255 (or 0% to 100%).

Correct — Valid `rgb()` value

<divstyle="background:rgb(255,0,128);">Content</div>

Correct — Using `background-color` for clarity

When you only need to set a color, prefer the specific background-color property over the shorthand:

<divstyle="background-color:rgba(255,0,0,0.5);">Semi-transparent red</div>

Correct — Valid shorthand with image and other properties

<divstyle="background:url('image.jpg') no-repeat center / cover;">Content</div>

Note the / between background-position (center) and background-size (cover) — this is required syntax in the shorthand.

CSS: “border-color”: “X” is not a “border-color” value.

The border-color property sets the color of an element's four borders. When the W3C validator reports that a given value "is not a border-color value," it means the value you provided doesn't match any recognized CSS color format. Common mistakes that trigger this error include using a bare number like 0 instead of a color, misspelling a color keyword (e.g., grren instead of green), forgetting the # prefix on a hex code, or passing an invalid argument to a color function.

This matters because browsers handle invalid CSS values unpredictably. When a browser encounters an unrecognized border-color value, it discards the entire declaration and falls back to the inherited or initial value (typically currentcolor). This can lead to inconsistent rendering across browsers and make your design behave in unexpected ways. Writing valid CSS ensures predictable, cross-browser results and keeps your stylesheets maintainable.

Valid color formats

The CSS border-color property accepts any valid <color> value, including:

Named keywords — red, blue, transparent, currentcolor, etc.
Hexadecimal — #rgb, #rrggbb, #rgba, #rrggbbaa
rgb() / rgba() — rgb(255, 0, 0) or rgb(255 0 0 / 50%)
hsl() / hsla() — hsl(0, 100%, 50%) or hsl(0 100% 50% / 0.5)

You can also specify one to four color values to target individual sides (top, right, bottom, left), following the standard CSS shorthand pattern.

Examples

Invalid: bare number instead of a color

A number like 0 is not a valid color value and triggers the error:

<style>

.box{

border:1px solid;

border-color:0;

}

</style>

Invalid: misspelled color keyword

Typos in color names are not recognized by CSS:

<style>

.box{

border:1px solid;

border-color: grren;

}

</style>

Invalid: hex code missing the `#` prefix

Without the leading #, the value is treated as an unknown keyword:

<style>

.box{

border:1px solid;

border-color: ff0000;

}

</style>

Fixed: using a named color keyword

<style>

.box{

border:1px solid;

border-color: green;

}

</style>

Fixed: using a hexadecimal value

<style>

.box{

border:1px solid;

border-color:#00ff00;

}

</style>

Fixed: using `rgb()` functional notation

<style>

.box{

border:1px solid;

border-color:rgb(0,128,0);

}

</style>

Fixed: using `hsl()` functional notation

<style>

.box{

border:1px solid;

border-color:hsl(120,100%,25%);

}

</style>

Fixed: setting different colors per side

You can provide up to four valid color values to control each border individually (top, right, bottom, left):

<style>

.box{

border:1px solid;

border-color: red green blue orange;

}

</style>

Fixed: using `transparent` or `currentcolor`

The special keywords transparent and currentcolor are also valid:

<style>

.box{

border:1px solid;

border-color: transparent;

}

.highlight{

color: navy;

border:2px solid;

border-color: currentcolor;

}

</style>

If you're unsure whether a value is a valid CSS color, check the MDN <color> data type reference for the complete list of accepted formats.

CSS: “border-radius”: “none” is not a “border-radius” value.

The border-radius property controls the rounding of an element's corners. Its valid values include lengths (e.g., 5px, 1em), percentages (e.g., 50%), and CSS-wide keywords like inherit, initial, and unset. Unlike many other border-related properties, border-radius has no none keyword in its value syntax.

This confusion typically arises because developers associate "no effect" with the keyword none, which works for properties like border: none or text-decoration: none. However, border-radius describes a geometric measurement — the radius of the corner curve — so "zero radius" (0) is the correct way to express no rounding.

Using an invalid value means the browser will ignore the entire declaration. This can lead to unexpected results: if a parent stylesheet or an earlier rule sets a border-radius, your none declaration won't override it, and the element will retain its rounded corners. Fixing this ensures your CSS is standards-compliant, behaves predictably across browsers, and passes W3C validation.

How to fix it

To remove rounding, replace none with 0.
To set a specific radius, use a valid length (5px, 0.5em), a percentage (50%), or a CSS-wide keyword (inherit, initial, unset).
The same rule applies to the longhand properties: border-top-left-radius, border-top-right-radius, border-bottom-right-radius, and border-bottom-left-radius.

Examples

Incorrect: using `none`

<style>

.box{

border-radius: none;/* "none" is not a valid border-radius value */

}

</style>

<divclass="box">Content</div>

Correct: removing rounded corners with `0`

<style>

.box{

border-radius:0;

}

</style>

<divclass="box">Content</div>

Correct: applying a specific radius

<style>

.circle{

width:100px;

height:100px;

border-radius:50%;

}

.rounded{

border-radius:8px;

}

.pill{

border-radius:9999px;

}

</style>

<divclass="circle">Circle</div>

<divclass="rounded">Rounded</div>

<divclass="pill">Pill shape</div>

Correct: resetting to the initial value

If you need to undo a border-radius set by another rule, you can use initial or unset, both of which resolve to 0:

<style>

.card{

border-radius:12px;

}

.card.sharp{

border-radius: initial;/* Resets to 0 */

}

</style>

<divclass="card">Rounded card</div>

<divclass="card sharp">Sharp-cornered card</div>

CSS: “border-radius”: X is not a “border-radius” value

The border-radius property accepts one to four values, each of which must be a valid <length> or <percentage>. You can also specify elliptical corners using a / separator with up to four values on each side. Any value that falls outside this syntax — such as a bare number without a unit, a misspelled keyword, a negative value, or a var() reference the validator can't resolve — will trigger this error.

Here are the most common reasons this error appears:

Missing units: Writing border-radius: 10 instead of border-radius: 10px. CSS requires explicit units for all non-zero length values.
Invalid keywords: Using a keyword like border-radius: large that isn't part of the CSS specification.
Negative values: The border-radius property does not accept negative lengths or percentages.
Unresolvable var() references: The W3C validator performs static analysis and cannot evaluate CSS custom properties. If you use var(--my-radius) in an inline style attribute, the validator has no way to confirm the variable holds a valid value, so it flags it as an error.
Malformed shorthand: Incorrect use of the / separator or too many values, such as border-radius: 10px 5px / 20px 15px 10px 5px 3px.

This matters for standards compliance and cross-browser consistency. While browsers are generally forgiving and will ignore invalid property values, this means the style silently fails — your element won't get the rounded corners you intended. Catching these errors during validation helps prevent subtle visual bugs.

How to fix it

Add units to any bare numeric values (except 0, which doesn't need a unit).
Remove negative values — use 0 as the minimum.
Check shorthand syntax — you can provide one to four values, optionally followed by / and one to four more values for elliptical radii.
Replace unresolvable var() references with static values for validation purposes, or move them into a <style> block where the custom property is defined (though the validator may still flag var() usage).
Use valid units such as px, em, rem, %, vw, etc.

Examples

Invalid: missing unit on a non-zero value

<divstyle="border-radius:10;"></div>

Fixed: adding the correct unit

<divstyle="border-radius:10px;"></div>

Invalid: negative value

<divstyle="border-radius:-5px;"></div>

Fixed: using a non-negative value

<divstyle="border-radius:5px;"></div>

Invalid: unrecognized keyword

<divstyle="border-radius: round;"></div>

Fixed: using a valid percentage for a circular shape

<divstyle="border-radius:50%;"></div>

Invalid: `var()` in inline style that the validator cannot resolve

<divstyle="border-radius:var(--my-radius);"></div>

Fixed: defining the custom property in a stylesheet

<!DOCTYPE html>

<htmllang="en">

<head>

<title>Border Radius Example</title>

<style>

:root{

--my-radius:8px;

}

.rounded{

border-radius:var(--my-radius);

}

</style>

</head>

<body>

<divclass="rounded">Rounded corners via custom property</div>

</body>

</html>

Note that even with the custom property properly defined, the W3C CSS validator may still flag var() usage because it performs static analysis without evaluating custom properties. This is a known limitation. If full validator compliance is important, use static values directly:

<divstyle="border-radius:8px;"></div>

Valid shorthand with elliptical radii

The / syntax lets you define horizontal and vertical radii separately:

<divstyle="border-radius:10px20px/5px15px;"></div>

This sets horizontal radii of 10px and 20px (alternating corners) and vertical radii of 5px and 15px, creating elliptical corners. Both sides of the / follow the same one-to-four value pattern.

CSS: “border-style”: “thick” is not a “border-style” value.

The border-style property controls the visual pattern of a border — whether it appears as a solid line, a series of dots, dashes, or other decorative styles. Its valid values are: none, hidden, dotted, dashed, solid, double, groove, ridge, inset, and outset.

The keyword thick is a valid value for border-width, which controls how wide or heavy the border appears. It's one of three named width keywords: thin, medium, and thick. When thick is mistakenly used as a border-style value, the browser cannot interpret the declaration, and the border may not render at all or may fall back to unexpected defaults.

This is a common mix-up because people often think of a "thick border" as a single concept, but CSS separates the concern into two distinct properties: the style (what it looks like) and the width (how thick it is). Both must be set correctly for the border to display as intended. Without a valid border-style, most browsers default to none, meaning no border is visible regardless of other border properties.

To fix the issue, replace thick in your border-style declaration with a valid style keyword, and move thick to border-width if you want a heavier border. Alternatively, you can use the border shorthand to set width, style, and color in a single declaration.

Examples

Incorrect: using `thick` as a border style

<divstyle="border-style: thick;">This border will not render correctly.</div>

The value thick is not recognized for border-style, so the declaration is invalid.

Correct: separating style and width

<divstyle="border-style: solid;border-width: thick;">This has a thick solid border.</div>

Here, solid defines the border pattern and thick defines the border width — each value is used with the correct property.

Correct: using a specific pixel width

<divstyle="border-style: dashed;border-width:4px;">This has a 4px dashed border.</div>

You can use any length value (like 4px or 0.25em) for border-width instead of the thick keyword for more precise control.

Correct: using the `border` shorthand

<divstyle="border: thick solid #333;">This uses the border shorthand.</div>

The border shorthand accepts width, style, and color in any order. This is often the most concise way to define a border and avoids confusion between the individual properties.

CSS: “border”: Too many values or values are not recognized.

CSS
border

The border shorthand property lets you set the width, style, and color of an element's border in a single declaration. The CSS specification allows up to three values, each corresponding to one of the longhand properties: border-width, border-style, and border-color. Each component may appear at most once, and the browser determines which value maps to which component based on the value's type. When the validator encounters more values than expected or a value it can't match to any of the three components, it raises this error.

This error commonly occurs for several reasons:

Too many values — Providing four values (like you might with margin or padding) doesn't work with border. Unlike box-model spacing properties, border does not accept per-side values in its shorthand.
Misspelled keywords — A typo like sollid instead of solid, or doted instead of dotted, produces an unrecognized value.
Invalid or unsupported values — Using values that don't belong to any of the three components, such as border: 2px solid black inset (mixing shorthand with a style that creates a duplicate).
Missing spaces — Writing 1pxsolid black instead of 1px solid black creates an unrecognized token.
Using border syntax for border-radius or other properties — Accidentally placing values like 5px 10px 5px 10px on border instead of on border-radius.

Fixing the issue means ensuring your border value contains only recognized values, with no more than one from each category:

Width: A length (e.g., 1px, 0.5em), 0, or a keyword (thin, medium, thick).
Style: One of none, hidden, dotted, dashed, solid, double, groove, ridge, inset, or outset.
Color: Any valid CSS color (e.g., red, #333, rgb(0, 0, 0), transparent).

If you need different borders on each side, use the side-specific properties (border-top, border-right, border-bottom, border-left) or the individual longhand properties (border-width, border-style, border-color), which do accept multiple values for each side.

Examples

Incorrect: too many values

<divstyle="border:1px2px solid black;">Content</div>

This provides two width values (1px and 2px), which the border shorthand does not allow. If you want different widths per side, use border-width separately.

Incorrect: misspelled keyword

<divstyle="border:2px sollid red;">Content</div>

The value sollid is not a recognized border style, causing the validator to reject the declaration.

Incorrect: four-value syntax used on `border`

<divstyle="border:1px2px1px2px solid grey;">Content</div>

The border shorthand does not support per-side values. This syntax is valid for border-width, not for border.

Correct: standard shorthand with all three components

<divstyle="border:2px solid black;">Content</div>

Correct: omitting optional components

You don't need to provide all three values. Any omitted component resets to its initial value (medium, none, and currentcolor respectively).

<pstyle="border: solid;">Content</p>

Correct: two components in any order

<pstyle="border: dashed #00f;">Content</p>

Correct: different borders per side using longhand properties

<divstyle="border-width:1px2px1px2px;border-style: solid;border-color: grey;">Content</div>

Correct: using side-specific shorthand properties

<divstyle="border-top:1px solid red;border-bottom:2px dashed blue;">Content</div>

CSS: “border”: “undefined” is not a “color” value.

The border shorthand property accepts up to three values: a width (e.g., 1px), a style (e.g., solid), and a color (e.g., black). When the validator encounters "undefined" in the color position, it rightfully rejects it because undefined is not a recognized CSS color keyword, hex value, or color function.

This issue most commonly appears in projects that use JavaScript to dynamically set inline styles. When a variable intended to hold a color value is undefined—perhaps because it wasn't initialized, a configuration value is missing, or a function didn't return a result—the rendered HTML ends up with a literal style="border: 1px solid undefined" in the markup. Build tools, templating engines, or server-side rendering can also produce this output if a variable isn't properly resolved.

Beyond failing validation, this is a real problem because browsers will discard the entire border declaration when they encounter an invalid value. This means the border won't render at all, which may break your layout or visual design in ways that are hard to debug. Ensuring valid CSS values keeps your styling predictable across all browsers.

How to fix it

Check for dynamic values. If the color is set via JavaScript or a templating engine, ensure the variable always resolves to a valid color string. Add fallback values or default assignments.
Replace the invalid value. Substitute undefined with a proper CSS color — a named color (red, black), a hex code (#333), an rgb() or hsl() function, or even transparent or currentcolor.
Remove the declaration. If no border is needed, remove the border property entirely rather than leaving an invalid value in place.

Examples

Incorrect: literal `undefined` as a color value

<divstyle="border:1px solid undefined;">Content</div>

The validator rejects undefined because it is not a valid CSS color.

Incorrect: JavaScript producing `undefined` in markup

constborderColor=undefined;// missing configuration

document.getElementById("box").style.border="2px dashed "+borderColor;

</script>

This produces border: 2px dashed undefined on the element.

Correct: using a valid color value

<divstyle="border:1px solid black;">Content</div>

Correct: using a hex code or `rgb()` function

<divstyle="border:2px dashed #ff6600;">Content</div>

<divstyle="border:3px dotted rgb(0,128,255);">Content</div>

Correct: providing a fallback in JavaScript

<divid="box">Content</div>

constborderColor=getUserColor()||"#333";

document.getElementById("box").style.border="2px solid "+borderColor;

</script>

By using || "#333", you ensure a valid color is always applied even when getUserColor() returns undefined.

Correct: using separate border properties

If you prefer more granular control, you can define each border sub-property individually:

<divstyle="border-width:1px;border-style: solid;border-color: black;">Content</div>

Valid `border` shorthand reference

The border shorthand follows this pattern:

selector{

border: <width> <style> <color>;

}

Width: 1px, 2px, thin, medium, thick
Style: solid, dashed, dotted, double, groove, ridge, inset, outset, none
Color: any valid CSS color — named colors (red, blue), hex (#000), rgb(), hsl(), currentcolor, or transparent

All three values are optional in the shorthand, but any value you do include must be valid. The string undefined is never a valid CSS value. If your styles are generated dynamically, always validate or sanitize the output before it reaches the HTML.

CSS: “border-width”: X is not a “border-width” value.

The border-width property controls the thickness of an element's border. According to the CSS specification, its accepted values fall into two categories:

Length values — any valid CSS length such as 1px, 0.25em, 2rem, 3pt, or 0.1cm. The value must not be negative.
Keywords — exactly three are defined: thin, medium, and thick. These map to implementation-defined sizes but are guaranteed to maintain the relationship thin ≤ medium ≤ thick.

A bare number like 5 (without a unit) is not valid, even though some browsers may silently accept it. Similarly, words like large, bold, normal, or color values like red are not valid border-width values. Percentage values (e.g., 10%) are also not accepted for border-width, unlike many other CSS properties that accept lengths.

This matters for several reasons. First, invalid CSS values cause the declaration to be ignored entirely, meaning the border may not render as intended — or may fall back to the initial value of medium, producing unexpected results. Second, relying on browser error-recovery behavior leads to inconsistent rendering across different browsers and versions. Third, valid CSS ensures your stylesheets are maintainable and predictable.

Common causes of this error include:

Missing units — writing border-width: 2 instead of border-width: 2px. The only unitless length allowed in CSS is 0.
Misspelled or invented keywords — using large, small, normal, or none instead of thin, medium, or thick.
Wrong value type — accidentally using a color name, percentage, or other non-length value.
Typos in units — writing 5xp instead of 5px.

To fix the issue, locate the offending border-width declaration and replace the invalid value with a proper CSS length (including its unit) or one of the three accepted keywords.

Examples

Invalid: using a non-existent keyword

<style>

.box{

border-style: solid;

border-width: large;/* "large" is not a valid border-width value */

}

</style>

<divclass="box">Content</div>

Fixed: using a valid keyword

<style>

.box{

border-style: solid;

border-width: thick;

}

</style>

<divclass="box">Content</div>

Invalid: missing unit on a number

<style>

.alert{

border: solid;

border-width:3;/* unitless number is not valid */

}

</style>

<divclass="alert">Warning</div>

Fixed: adding a proper unit

<style>

.alert{

border: solid;

border-width:3px;

}

</style>

<divclass="alert">Warning</div>

Invalid: using a percentage

<style>

.panel{

border-style: solid;

border-width:5%;/* percentages are not valid for border-width */

}

</style>

<divclass="panel">Panel</div>

Fixed: using a length value instead

<style>

.panel{

border-style: solid;

border-width:0.3em;

}

</style>

<divclass="panel">Panel</div>

Using multiple values with shorthand

The border-width property accepts one to four values (for top, right, bottom, left), and each must independently be valid:

<style>

.card{

border-style: solid;

border-width: thin 2px medium 1px;

}

</style>

<divclass="card">Card content</div>

Replace any invalid border-width value with a recognized CSS length (always including the unit, except for 0) or one of the keywords thin, medium, or thick to resolve the validation error.

CSS: “border”: X is not a “color” value.

CSS: “border”: X negative values are not allowed.

border

CSS: “box-shadow”: X is not a “box-shadow” value.

The box-shadow property applies one or more shadow effects to an element's box. The W3C CSS validator checks that each value in the declaration conforms to the specification. When it encounters something it doesn't recognize — such as a unitless number (other than 0), a misspelled keyword, or values arranged in the wrong order — it reports that the value is not valid for box-shadow.

The correct syntax for a single box-shadow value is:

box-shadow: none | [inset? && <offset-x> <offset-y> <blur-radius>? <spread-radius>? <color>?]

inset (optional): If present, the shadow is drawn inside the element's border.
<offset-x> and <offset-y> (required): Horizontal and vertical offsets. Must be valid CSS lengths with units (e.g., px, em, rem). The value 0 is the only length that doesn't require a unit.
<blur-radius> (optional): Must be a non-negative length. Defaults to 0.
<spread-radius> (optional): Can be positive or negative. Defaults to 0. You can only include this if you also include <blur-radius>.
<color> (optional): Any valid CSS color. Can appear at the beginning or end of the value list.

Common causes of this validation error include:

Missing units on length values — Writing 10 10 instead of 10px 10px.
Invalid or misspelled keywords — Using something like outerbox or shadows instead of inset or none.
Too many or too few values — Providing five length values when the maximum is four.
Vendor prefixes — Using -webkit-box-shadow or non-standard values that the standard validator rejects.
Invalid color values — Using a malformed color like rgb(0,0,0,0.5) (missing the a in rgba for CSS3 validation) or a typo in a named color.
Incorrect value order — Placing the color between the length values instead of at the start or end.

Fixing this issue ensures your CSS is standards-compliant, which improves cross-browser consistency and reduces the risk of unexpected rendering behavior.

Examples

Missing units on length values

Unitless numbers (except 0) are not valid CSS lengths. This is one of the most common triggers for this error.

<divstyle="box-shadow:10105rgba(0,0,0,0.5);">

Shadow text

</div>

<divstyle="box-shadow:10px10px5pxrgba(0,0,0,0.5);">

Shadow text

</div>

Invalid keyword

Only none and inset are valid keywords for box-shadow. Any other keyword triggers the error.

<divstyle="box-shadow: outset 4px4px8px#333;">

Shadow text

</div>

<divstyle="box-shadow: inset 4px4px8px#333;">

Shadow text

</div>

Color value in the wrong position or malformed

The color value should appear either first or last in the shadow definition. Some validators are strict about placement, and a malformed color will always fail.

<divstyle="box-shadow:2px red 2px5px;">

Shadow text

</div>

<divstyle="box-shadow:2px2px5px red;">

Shadow text

</div>

Using zero without units alongside other values

While 0 alone doesn't require a unit, mixing it into the declaration is fine — just make sure other values have proper units.

<divstyle="box-shadow:0010px2pxrgba(0,0,0,0.75);">

Shadow text

</div>

Multiple shadows

Multiple shadow values are separated by commas. Each individual shadow must independently follow the correct syntax.

<divstyle="box-shadow:2px2px5px#888, inset 0010px2px blue;">

Multiple shadows

</div>

Vendor-prefixed property

The W3C validator does not recognize vendor-prefixed properties. If you need them for legacy browser support, keep the standard property alongside.

<divstyle="-webkit-box-shadow:3px3px6px#000;">

Shadow text

</div>

<divstyle="box-shadow:3px3px6px#000;">

Shadow text

</div>

CSS: “box-shadow”: X is not a “color” value.

The box-shadow property applies one or more shadow effects to an element. Its syntax accepts several values in a flexible order:

box-shadow: <offset-x> <offset-y> <blur-radius>? <spread-radius>? <color>? inset?;

The <color> component is optional — if omitted, it defaults to currentcolor. However, when a color is provided, it must be a valid CSS color value. The validator raises this error when it encounters something in the color position that doesn't match any recognized color format.

Common causes of this error include:

Misspelled color names — e.g., greyy instead of grey, or balck instead of black.
Invalid hex codes — e.g., #GGG or #12345 (hex codes must be 3, 4, 6, or 8 hex digits).
Fabricated color names — e.g., banana or darkwhite, which are not part of the CSS named colors specification.
Malformed function syntax — e.g., rgb(0,0,0,0.3) using the legacy comma syntax with four values instead of rgba(), or missing parentheses.
Incorrect value order — placing values in an unexpected position can cause the validator to misinterpret a non-color value as a color attempt.

This matters for standards compliance because browsers may silently ignore an invalid box-shadow declaration entirely, meaning your intended shadow effect won't render. Using valid CSS ensures consistent behavior across browsers and passes validation checks.

Recognized CSS color formats

The following formats are valid for the color component:

Named colors: red, blue, transparent, currentcolor, etc.
Hex codes: #000, #0000, #000000, #00000080
RGB/RGBA: rgb(0, 0, 0), rgba(0, 0, 0, 0.5), or the modern rgb(0 0 0 / 50%)
HSL/HSLA: hsl(0, 0%, 0%), hsla(0, 0%, 0%, 0.5), or hsl(0 0% 0% / 50%)

Examples

Incorrect — misspelled or invalid color values

<divstyle="box-shadow:2px4px8px balck;">Typo in color</div>

<divstyle="box-shadow:2px4px8px banana;">Invalid color name</div>

<divstyle="box-shadow:2px4px8px#12345;">Bad hex code</div>

Correct — valid color values

<divstyle="box-shadow:2px4px8px black;">Named color</div>

<divstyle="box-shadow:2px4px8px#333;">Hex color</div>

<divstyle="box-shadow:2px4px8pxrgba(0,0,0,0.3);">Semi-transparent</div>

<divstyle="box-shadow:2px4px8pxhsl(210,50%,40%);">HSL color</div>

Correct — omitting the color entirely

If you want the shadow to inherit the element's text color, you can omit the color value altogether. This is valid and avoids the error:

<divstyle="box-shadow:2px4px8px;">Uses currentcolor</div>

Correct — multiple shadows with valid colors

<divstyle="box-shadow:2px2px4pxrgba(0,0,0,0.2), inset 006px#ccc;">

Multiple shadows

</div>

To resolve this validation error, check the exact value the validator flags (the "X" in the error message), verify its spelling against the list of CSS named colors, and ensure any hex or function-based color uses correct syntax. If the color isn't needed, simply remove it and let the browser default to currentcolor.

CSS: “clip-path”: X is not a “clip-path” value.

The clip-path property defines a clipping region that controls which parts of an element are visible. It accepts a specific set of value types, and any deviation from the expected syntax will trigger a validation error. The validator checks your CSS against the specification and flags values that don't conform.

The accepted value types for clip-path are:

none — No clipping (the default).
Basic shape functions — inset(), circle(), ellipse(), polygon(), and path().
url() reference — Points to an SVG <clipPath> element, e.g., url(#myClip).
Geometry-box keywords — border-box, padding-box, content-box, margin-box, fill-box, stroke-box, view-box. These can be used alone or combined with a basic shape.

Here are the most common mistakes that cause this error:

Missing units on length values. Writing circle(50 at 50% 50%) is invalid because 50 needs a unit like px, em, or %. The value 0 is the only length that doesn't require a unit.
Wrong separators. In circle() and ellipse(), the position coordinates after at must be separated by spaces, not commas. In polygon(), each coordinate pair uses a space between x and y, while commas separate the points from each other.
Malformed path() data. The SVG path string inside path() must be wrapped in quotes, e.g., path("M0 0 L100 0 L100 100 Z").
Typos or unsupported functions. Using a function name the specification doesn't define, or misspelling one like cirlce(), will trigger the error.
Invalid polygon() fill-rule. If you specify a fill rule in polygon(), it must be nonzero or evenodd, followed by a comma before the first point.

Getting clip-path syntax right matters for standards compliance and cross-browser consistency. Browsers may silently ignore an invalid clip-path value, meaning your intended visual effect simply won't appear — and you may not realize why. Validating your CSS catches these issues early.

Here is a quick reference for the correct syntax of each basic shape function:

circle(<radius> at <cx> <cy>) — Radius is a length or percentage. Position uses spaces, not commas.
ellipse(<rx> <ry> at <cx> <cy>) — Both radii are lengths or percentages.
inset(<top> <right> <bottom> <left> round <border-radius>) — Offsets are lengths or percentages. The round keyword and border-radius are optional.
polygon([<fill-rule>,] <x1> <y1>, <x2> <y2>, ...) — Space between x and y within a point; comma between points.
path("<SVG path data>") — Path data string must be quoted.

Examples

Invalid `clip-path` values

<style>

/* Invalid: unitless radius; comma between position coordinates */

.clip-a{

clip-path:circle(50 at 50%,50%);

}

/* Invalid: commas between x and y within each point */

.clip-b{

clip-path:polygon(0%,0%,100%,0%,100%,100%,0%,100%);

}

/* Invalid: path data not wrapped in quotes */

.clip-c{

clip-path:path(M0 0 L100 0 L100 100 Z);

}

/* Invalid: misspelled function name */

.clip-d{

clip-path:cirlce(50% at 50%50%);

}

</style>

Valid `clip-path` values

<style>

/* Valid circle: radius has a unit; position uses spaces */

.clip-a{

clip-path:circle(50px at 50%50%);

}

/* Valid polygon: space between x and y, commas between points */

.clip-b{

clip-path:polygon(0%0%,100%0%,100%100%,0%100%);

}

/* Valid path: SVG data is quoted */

.clip-c{

clip-path:path("M0 0 L100 0 L100 100 Z");

}

/* Valid inset with rounded corners */

.clip-d{

clip-path:inset(10%20%10%20% round 8px);

}

/* Valid geometry-box keyword combined with a shape */

.clip-e{

clip-path: padding-box circle(50% at 50%50%);

}

/* Valid: referencing an SVG clipPath */

.clip-f{

clip-path:url(#roundClip);

}

</style>

Full example with SVG `<clipPath>` reference

<!doctype html>

<htmllang="en">

<head>

<title>Valid clip-path with SVG reference</title>

<style>

.clipped{

clip-path:url(#roundClip);

width:200px;

height:200px;

background: coral;

}

</style>

</head>

<body>

<svgwidth="0"height="0"aria-hidden="true">

<clipPathid="roundClip"clipPathUnits="objectBoundingBox">

<circlecx="0.5"cy="0.5"r="0.5"></circle>

</clipPath>

</svg>

<divclass="clipped">Clipped element</div>

</body>

</html>

When you encounter this validation error, carefully check the value reported in the error message. Compare it against the accepted syntax for the function you're using, paying close attention to units, separators, and quoting. Small syntax differences — a comma where a space should be, or a missing unit — are the most frequent culprits.

CSS: “color”: “X” is not a “color” value.

css
color

The color property, along with properties like background-color, border-color, and outline-color, expects values that conform to the CSS Color specification. The validator triggers this error when it encounters something that doesn't match any valid color syntax. Common causes include:

Plain numbers like 0 or 123 — numbers alone aren't colors.
Typos in color keywords such as grean instead of green, or trasparent instead of transparent.
Malformed hex values like #GGG (invalid hex characters) or #12345 (wrong number of digits — hex colors must be 3, 4, 6, or 8 digits).
Incorrect function syntax such as rgb(255 255 255 / 50) missing the % on the alpha value, or using legacy commas mixed with modern space-separated syntax.
Missing units or hash symbols like 000000 instead of #000000.

This matters because browsers handle invalid color values unpredictably. Most will simply ignore the declaration entirely, which means the element inherits its color from a parent or falls back to the browser default — potentially making text unreadable against its background. Writing valid CSS ensures consistent rendering across all browsers and improves the maintainability of your code.

Valid CSS color formats

CSS supports several color formats:

Format	Example	Notes
Named colors	`red`, `blue`, `transparent`	148 predefined keywords
Hexadecimal	`#ff0000`, `#f00`	3, 4, 6, or 8 digits
`rgb()` / `rgba()`	`rgb(255, 0, 0)`	Comma or space-separated
`hsl()` / `hsla()`	`hsl(0, 100%, 50%)`	Hue, saturation, lightness
`currentcolor`	`currentcolor`	Inherits the current `color` value

Examples

Invalid: plain number as a color

A bare number is not a recognized color value:

<style>

.example{

color:0;

}

</style>

Invalid: typo in a color keyword

<style>

.example{

background-color: trasparent;

}

</style>

Invalid: hex value missing the `#` prefix

<style>

.example{

color:000000;

}

</style>

Invalid: hex value with wrong digit count

<style>

.example{

color:#12345;

}

</style>

Fixed: using a named color keyword

<style>

.example{

color: black;

}

</style>

Fixed: using a hexadecimal color

<style>

.example{

color:#000000;

}

</style>

Fixed: using `rgb()`

<style>

.example{

color:rgb(0,0,0);

}

</style>

Fixed: using `hsl()`

<style>

.example{

color:hsl(0,0%,0%);

}

</style>

Fixed: using `rgba()` for semi-transparent color

<style>

.example{

color:rgba(0,0,0,0.5);

}

</style>

Fixed: correcting the `transparent` keyword typo

<style>

.example{

background-color: transparent;

}

</style>

If you're unsure whether a value is valid, browser DevTools can help — most browsers will strike through or ignore invalid property values in the Styles panel, giving you a quick visual indicator of the problem.

CSS: “color”: X is not a valid color 3 or 6 hexadecimals numbers.

css
color

Hexadecimal color values in CSS must follow a specific format: the # symbol followed by exactly 3 or 6 hexadecimal digits. Each digit can be a number from 0 to 9 or a letter from A to F (case-insensitive). A 3-digit hex code is shorthand where each digit is expanded by duplication — for example, #F00 is equivalent to #FF0000. Common mistakes that trigger this error include using the wrong number of digits (e.g., 1, 2, 4, or 5), including non-hexadecimal characters (like G, Z, or special symbols), or omitting the # prefix.

The color CSS property sets the foreground color of an element's text and text decorations. It also establishes the currentcolor value, which acts as an indirect value for other properties like border-color. Because color cascades to many visual aspects of an element, an invalid value can cause the entire declaration to be ignored, meaning the element may inherit an unexpected color or fall back to browser defaults.

This matters for consistency across browsers. While some browsers may attempt to guess what you meant with a malformed hex code, others will discard the value entirely. This leads to unpredictable rendering. Using valid color values ensures your styles are applied reliably everywhere.

Note that CSS also supports 4-digit and 8-digit hex values (which include an alpha/transparency channel, e.g., #F00A or #FF0000AA). However, the W3C validator's inline style checker may not recognize these newer formats depending on the CSS level being validated. If you need transparency, consider using the rgba() function for broader validation compatibility.

Examples

Invalid hex color values

These examples will trigger the validation error:

<pstyle="color:#F;">Hello</p>

<pstyle="color:#FF;">Hello</p>

<pstyle="color:#FF00;">Hello</p>

<pstyle="color:#FF000;">Hello</p>

<pstyle="color:#FG0000;">Hello</p>

<pstyle="color: FF0000;">Hello</p>

Valid hex color values

Use exactly 3 or 6 hexadecimal digits after the #:

<pstyle="color:#F00;">Hello</p>

<pstyle="color:#FF0000;">Hello</p>

<pstyle="color:#FFF;">Hello</p>

<pstyle="color:#333333;">Hello</p>

<pstyle="color:#3a7bd5;">Hello</p>

Alternative color formats

If hex values are causing issues, CSS offers several other valid ways to specify colors:

<pstyle="color: red;">Hello</p>

<pstyle="color:rgb(255,0,0);">Hello</p>

<pstyle="color:rgba(255,0,0,0.5);">Hello</p>

<pstyle="color:hsl(0,100%,50%);">Hello</p>

Examples

Invalid usage

Fixed usage

Examples

Incorrect: using a colon as the separator

Incorrect: using units in the ratio

Incorrect: using zero in the ratio

Correct: standard ratio with a slash

Correct: single number (height defaults to 1)

Correct: square ratio

Correct: using the auto keyword

Correct: combining auto with a fallback ratio

Correct: using global CSS values

Examples

Invalid values

Corrected values

Multiple background layers

How to fix it

Examples

❌ Incomplete hex value (triggers the error)

✅ Fixed with a valid hex color

❌ Truncated or invalid hex digits

✅ Fixed with a proper 3-digit shorthand hex color

✅ Alternative valid color formats

✅ Defensive approach for dynamic values

Valid color formats

Examples

Invalid: bare number as a color

Invalid: misspelled keyword

Invalid: quoted string

Invalid: malformed hex code

Fixed: using a named color keyword

Fixed: using a hex color

Fixed: using rgb() notation

Fixed: using rgba() for semi-transparency

Fixed: using hsl() notation

Fixed: using transparent

Why this happens

Why it matters

How to fix it

Examples

Incorrect: legacy WebKit gradient syntax

Incorrect: made-up gradient shorthand

Correct: standard linear gradient

Correct: solid color background

Correct: gradient with a fallback for older browsers

Correct: relative color syntax with a fallback

Examples

Missing url() function

Typo in gradient function name

Invalid gradient syntax

Unescaped special characters in URL

Vendor-prefixed values

Multiple backgrounds with incorrect separator

Moving styles to an external stylesheet

How to fix it

Examples

Incorrect: bare filename without url()

Incorrect: misspelled function name

Incorrect: missing parentheses in url

Incorrect: invalid keyword

Correct: using url() with a file path

Correct: using none to explicitly set no background image

Correct: using a gradient function

Correct: multiple background images

Correct: using a <style> block

Incorrect Example

Correct Examples

How to fix it

Examples

Invalid: bare direction keyword

Fixed: using the to keyword

Fixed: using an angle

Full document example

How to Fix

Examples

Incorrect — Typo in color name

Correct — Valid color name

Incorrect — Malformed hex code

Correct: using the `auto` keyword

Correct: combining `auto` with a fallback ratio

Fixed: using `rgb()` notation

Fixed: using `rgba()` for semi-transparency

Fixed: using `hsl()` notation

Fixed: using `transparent`

Missing `url()` function

Incorrect: bare filename without `url()`

Incorrect: missing parentheses in `url`

Correct: using `url()` with a file path

Correct: using `none` to explicitly set no background image

Correct: using a `<style>` block

Fixed: using the `to` keyword

Incorrect — Broken `rgb()` syntax

Correct — Valid `rgb()` value

Correct — Using `background-color` for clarity

Invalid: hex code missing the `#` prefix

Fixed: using `rgb()` functional notation

Fixed: using `hsl()` functional notation

Fixed: using `transparent` or `currentcolor`

Incorrect: using `none`

Correct: removing rounded corners with `0`

Invalid: `var()` in inline style that the validator cannot resolve

Incorrect: using `thick` as a border style

Correct: using the `border` shorthand

Incorrect: four-value syntax used on `border`

Incorrect: literal `undefined` as a color value

Incorrect: JavaScript producing `undefined` in markup

Correct: using a hex code or `rgb()` function

Valid `border` shorthand reference