DevToolBoxGRATIS
Blog

Calculadora de especificidad CSS y reglas explicadas

9 min de lecturapor DevToolBox

CSS specificity is the algorithm browsers use to decide which CSS rule applies when multiple rules target the same element. Understanding CSS specificity is essential for writing maintainable stylesheets, debugging layout issues, and avoiding the dreaded !important hack. This comprehensive guide covers the specificity hierarchy, calculation methods, cascade layers, modern pseudo-classes, and battle-tested best practices.

Optimize your CSS with our CSS Minifier tool →

1. What Is CSS Specificity?

Specificity is a weight assigned to a CSS selector that determines which declaration takes effect when multiple rules match the same element. It is NOT about source order alone — a more specific selector always wins, regardless of where it appears in the stylesheet.

Consider this example where two rules target the same element:

<!-- HTML -->
<header id="header" class="site-header">My Website</header>

/* CSS */
#header {
  color: blue;     /* Specificity: (1,0,0) — wins! */
}

.site-header {
  color: red;      /* Specificity: (0,1,0) — loses */
}

/* Result: text is blue, because #header (1,0,0) > .site-header (0,1,0) */

Even though the second rule comes later in the source, the first rule wins because an ID selector (#header) has higher specificity than a class selector (.site-header). The browser calculates a specificity value for each selector and applies the declaration with the highest value.

2. The Specificity Hierarchy

CSS specificity follows a strict hierarchy with four levels. From highest to lowest priority:

  1. Inline styles — Written directly in the HTML style attribute. Specificity: (1,0,0,0)
  2. ID selectors — e.g., #navbar, #main-content. Specificity: (0,1,0,0)
  3. Class selectors, attribute selectors, pseudo-classes — e.g., .btn, [type="text"], :hover, :focus, :nth-child(). Specificity: (0,0,1,0)
  4. Element selectors and pseudo-elements — e.g., h1, div, ::before, ::after. Specificity: (0,0,0,1)

The universal selector (*), combinators (+, ~, >, space), and the negation pseudo-class (:not()) itself do NOT add specificity. However, selectors inside :not() DO count.

/* Hierarchy demonstration */

/* Level 4: Element selector — (0,0,1) */
p { color: black; }

/* Level 3: Class selector — (0,1,0) — overrides element */
.text { color: gray; }

/* Level 3: Attribute selector — (0,1,0) — same level as class */
[data-theme="dark"] { color: white; }

/* Level 3: Pseudo-class — (0,1,0) — same level as class */
p:hover { color: blue; }

/* Level 2: ID selector — (1,0,0) — overrides all above */
#intro { color: green; }

/* Level 1: Inline style — (1,0,0,0) — overrides everything */
/* <p id="intro" style="color: red;">This is red</p> */

3. Calculating Specificity — The (a,b,c) Notation

Specificity is commonly expressed as a tuple (a, b, c) where a = number of ID selectors, b = number of class selectors, attribute selectors, and pseudo-classes, and c = number of element selectors and pseudo-elements. Some documentation uses a four-part notation (i, a, b, c) where i represents inline styles.

Here are examples showing how to calculate specificity step by step:

/* Example 1: p.intro */
/* Elements: p = 1 → c = 1 */
/* Classes:  .intro = 1 → b = 1 */
/* IDs:      none → a = 0 */
/* Specificity: (0, 1, 1) */

/* Example 2: #main .content p */
/* Elements: p = 1 → c = 1 */
/* Classes:  .content = 1 → b = 1 */
/* IDs:      #main = 1 → a = 1 */
/* Specificity: (1, 1, 1) */

/* Example 3: div#sidebar ul li.active a:hover */
/* Elements: div, ul, li, a = 4 → c = 4 */
/* Classes:  .active, :hover = 2 → b = 2 */
/* IDs:      #sidebar = 1 → a = 1 */
/* Specificity: (1, 2, 4) */

/* Example 4: body > main#content div.wrapper p.text span */
/* Elements: body, main, div, p, span = 5 → c = 5 */
/* Classes:  .wrapper, .text = 2 → b = 2 */
/* IDs:      #content = 1 → a = 1 */
/* Specificity: (1, 2, 5) */

/* Example 5: .nav .dropdown .dropdown-item:first-child::after */
/* Elements: none (but ::after = 1) → c = 1 */
/* Classes:  .nav, .dropdown, .dropdown-item, :first-child = 4 → b = 4 */
/* IDs:      none → a = 0 */
/* Specificity: (0, 4, 1) */

Comparing specificity: Compare from left to right. A higher number in an earlier position always wins. (1,0,0) beats (0,15,15) because 1 ID outweighs any number of classes or elements. There is no "carry over" — 15 classes do NOT equal 1 ID.

4. Specificity Examples Table — 15+ Selectors Ranked

The following table ranks common CSS selectors from lowest to highest specificity:

#SelectorSpecificity (a,b,c)Category
1*(0,0,0)Universal
2div(0,0,1)Element
3ul li(0,0,2)2 elements
4ul ol + li(0,0,3)3 elements
5h1 + p::first-line(0,0,3)2 elements + 1 pseudo-element
6.btn(0,1,0)1 class
7li.active(0,1,1)1 class + 1 element
8[type="text"](0,1,0)1 attribute
9a:hover(0,1,1)1 pseudo-class + 1 element
10div.container p.text(0,2,2)2 classes + 2 elements
11.nav .nav-item .nav-link(0,3,0)3 classes
12#header(1,0,0)1 ID
13#header .logo(1,1,0)1 ID + 1 class
14#header nav ul li.active a(1,1,4)1 ID + 1 class + 4 elements
15#main #sidebar .widget(2,1,0)2 IDs + 1 class
16#a #b #c .x .y .z(3,3,0)3 IDs + 3 classes

5. !important — What It Does, Why to Avoid, When Acceptable

The !important declaration overrides normal specificity calculations entirely. A rule with !important beats any rule without it, regardless of specificity scores.

Syntax:

/* Normal rule */
.button {
  background: blue;     /* Specificity: (0,1,0) */
}

/* !important overrides everything without !important */
p {
  background: red !important;   /* Wins over ANY non-!important rule */
}

/* When two rules both have !important, specificity decides */
#main .button {
  background: green !important;  /* Specificity: (1,1,0) — wins */
}
.button {
  background: red !important;    /* Specificity: (0,1,0) — loses */
}

/* The !important escalation problem */
.header { color: blue !important; }
/* Now you need this to override: */
#header.header { color: red !important; }
/* And then someone adds this: */
#page #header.header { color: green !important; }
/* This quickly becomes unmaintainable! */

Why to avoid !important:

  • It breaks the natural cascade and makes debugging extremely difficult.
  • It creates an escalation war — once you use !important, the only way to override it is with another !important combined with equal or higher specificity.
  • It makes refactoring dangerous because removing one !important can break styles elsewhere.
  • It makes stylesheets unmaintainable at scale.

When !important is acceptable:

  • Utility classes: Frameworks like Tailwind CSS use !important on utility classes to ensure they always override component styles (e.g., .hidden { display: none !important; }).
  • Overriding third-party CSS: When you cannot modify vendor styles and specificity alone is not sufficient.
  • Accessibility overrides: User stylesheets for high contrast or large text may legitimately use !important.
  • Email HTML: Some email clients require !important to override their default styles.

Priority order with !important: Normal author styles → !important author styles → !important user styles → !important user-agent (browser) styles. Transition declarations and animation declarations have their own special handling in the cascade.

6. Cascade Layers — @layer

CSS Cascade Layers (introduced in 2022, supported in all modern browsers) add a new dimension to the cascade that sits between specificity and source order. Layers let you control which groups of styles take priority without wrestling with specificity.

Basic Syntax:

/* Declare layer order (layers listed first have lowest priority) */
@layer base, components, utilities;

/* Add styles to each layer */
@layer base {
  h1 { color: black; font-size: 2rem; }
  a { color: blue; text-decoration: underline; }
}

@layer components {
  .card h1 { color: navy; }       /* Higher priority than base */
  .btn { padding: 8px 16px; background: blue; color: white; }
}

@layer utilities {
  .text-red { color: red; }       /* Highest priority among layers */
  .hidden { display: none; }
}

/* Unlayered styles (highest priority for non-!important) */
h1 { font-family: Georgia, serif; }

Layer order matters: Layers declared later have higher priority. In the example above, utilities styles override components styles, which override base styles — regardless of specificity within each layer.

How layers interact with specificity:

  • Styles in a higher-priority layer always beat styles in a lower-priority layer, even if the lower layer has higher specificity.
  • Within the same layer, normal specificity rules apply.
  • Unlayered styles have the highest priority among normal (non-!important) styles.
  • With !important, the order reverses: !important in an earlier (lower-priority) layer beats !important in a later (higher-priority) layer.

Practical example:

@layer base, theme, components;

@layer base {
  /* Even with #id selector (1,0,0), this loses to a class in 'components' */
  #sidebar { background: white; }
}

@layer components {
  /* This wins because 'components' layer has higher priority */
  .sidebar { background: gray; }
}

/* !important reversal: earlier layer wins with !important */
@layer base {
  #sidebar { background: white !important; }  /* WINS with !important */
}

@layer components {
  .sidebar { background: gray !important; }   /* Loses despite later layer */
}

7. :where() and :is() — Specificity Control

The :where() and :is() pseudo-classes accept a selector list and match any element that matches at least one of the selectors. The critical difference is how they affect specificity.

:where() — Zero Specificity

:where() always contributes zero specificity, no matter what selectors are inside it. This makes it perfect for writing easily-overridable base styles.

/* :where() — zero specificity regardless of arguments */

/* Specificity: (0,0,1) — only the 'a' element counts */
:where(#nav, .menu, header) a {
  color: blue;
  text-decoration: none;
}

/* This easily overrides the above because (0,1,0) > (0,0,1) */
.custom-link {
  color: red;  /* Wins! */
}

/* Great for CSS resets that should be easy to override */
:where(h1, h2, h3, h4, h5, h6) {
  margin: 0;
  font-weight: bold;
}

/* Any class can override the reset */
.light-heading {
  font-weight: 300;  /* Easily overrides :where() */
}

:is() — Takes the Highest Argument's Specificity

:is() takes the specificity of its most specific argument. If one of the selectors inside :is() is an ID, the entire :is() gets ID-level specificity.

/* :is() — takes the specificity of the most specific argument */

/* Specificity: (1,0,1) — #nav is the highest argument, plus 'a' */
:is(#nav, .menu, header) a {
  color: blue;
}

/* This does NOT override because (0,1,0) < (1,0,1) */
.custom-link {
  color: red;  /* Loses! */
}

/* :is() for grouping with consistent specificity */
/* Before (repetitive): */
.card h1, .card h2, .card h3 { color: navy; }

/* After (clean): */
.card :is(h1, h2, h3) { color: navy; }
/* Specificity: (0,1,1) — .card + highest arg (h1/h2/h3 = element) */

Comparison example:

/* Side-by-side comparison */

/* :where() version — Specificity: (0,0,1) */
:where(.alert, .warning, .error) p { color: red; }

/* :is() version — Specificity: (0,1,1) */
:is(.alert, .warning, .error) p { color: red; }

/* A simple class easily overrides :where() but not :is() */
.normal-text { color: black; }
/* ✓ Overrides :where() version — (0,1,0) > (0,0,1) */
/* ✗ Does NOT override :is() version — (0,1,0) < (0,1,1) */

When to use which: Use :where() for reset styles, default themes, and library CSS that consumers should easily override. Use :is() for grouping selectors when you want to maintain normal specificity.

8. :not() and :has() — Specificity of Negation and Relational Pseudo-Classes

:not() itself adds zero specificity, but its argument contributes its full specificity. This is the same behavior as :is().

:has() (the "parent selector") also contributes the specificity of its most specific argument, just like :is() and :not().

Examples:

/* :not() specificity examples */

/* div:not(.active) — Specificity: (0,1,1) */
/* :not() itself = 0, but .active inside = (0,1,0), plus div = (0,0,1) */
div:not(.active) {
  opacity: 0.5;
}

/* p:not(#hero) — Specificity: (1,0,1) */
/* :not() = 0, but #hero inside = (1,0,0), plus p = (0,0,1) */
p:not(#hero) {
  font-size: 1rem;
}

/* :not() with multiple arguments (selector list) */
/* a:not(.btn, .link) — Specificity: (0,1,1) */
/* Takes highest argument: .btn and .link are both (0,1,0) */
a:not(.btn, .link) {
  text-decoration: underline;
}


/* :has() specificity examples */

/* article:has(img) — Specificity: (0,0,2) */
/* :has() = 0, img inside = (0,0,1), plus article = (0,0,1) */
article:has(img) {
  display: grid;
  grid-template-columns: 1fr 2fr;
}

/* .card:has(> .featured) — Specificity: (0,2,0) */
/* :has() = 0, .featured inside = (0,1,0), plus .card = (0,1,0) */
.card:has(> .featured) {
  border: 2px solid gold;
}

/* div:has(#special) — Specificity: (1,0,1) */
/* :has() = 0, #special inside = (1,0,0), plus div = (0,0,1) */
div:has(#special) {
  background: lightyellow;
}

Important: A common mistake is thinking :not() adds no specificity. In fact, div:not(.active) has specificity (0,1,1) — the .active inside :not() adds class-level specificity.

9. Inline Styles vs Stylesheet — Specificity Value (1,0,0,0)

Inline styles written directly in the HTML style attribute have a specificity of (1,0,0,0) in the four-part notation. This means they override any selector-based rule, no matter how many IDs, classes, or elements it contains.

Example:

<!-- Inline style beats everything except !important -->
<p id="intro" class="text hero-text"
   style="color: red;">
  This text is RED
</p>

/* None of these can override the inline style */
p { color: black; }                        /* (0,0,1) — loses */
.text { color: black; }                    /* (0,1,0) — loses */
.text.hero-text { color: black; }          /* (0,2,0) — loses */
#intro { color: black; }                   /* (1,0,0) — loses */
#intro.text.hero-text { color: black; }    /* (1,2,0) — loses */

/* Only !important can override inline styles */
#intro { color: black !important; }        /* Wins! */

How to override inline styles from a stylesheet:

  • Use !important in your stylesheet rule (generally discouraged).
  • Use JavaScript to remove or modify the inline style.
  • Use a cascade layer with !important for controlled overriding.
  • Avoid inline styles in the first place — use classes instead.

Why to avoid inline styles: They cannot be overridden without !important, they mix concerns (HTML structure with CSS presentation), they cannot use pseudo-classes or pseudo-elements, they cannot use media queries, and they are difficult to maintain at scale.

10. Common Specificity Battles

In real-world projects, you frequently encounter specificity conflicts. Here are the most common scenarios and how to resolve them:

Overriding Framework Styles (Bootstrap, Material UI)

CSS frameworks often use moderately specific selectors. When your custom styles do not apply, it is usually because the framework selector has higher specificity.

/* Bootstrap button has specificity (0,1,0) */
.btn-primary {
  background-color: #0d6efd;
}

/* Your custom style — same specificity, but source order wins */
/* PROBLEM: If Bootstrap CSS loads AFTER yours, it overrides you */
.btn-primary {
  background-color: #7c3aed;  /* May or may not work! */
}

/* SOLUTION 1: Increase specificity slightly */
.my-theme .btn-primary {
  background-color: #7c3aed;  /* (0,2,0) — always wins */
}

/* SOLUTION 2: Use :where() in your base + normal class for overrides */
:where(.btn-primary) {
  background-color: #0d6efd;  /* (0,0,0) — easy to override */
}
.btn-primary {
  background-color: #7c3aed;  /* (0,1,0) — wins */
}

/* SOLUTION 3: Use @layer */
@layer framework, custom;

@layer framework {
  .btn-primary { background-color: #0d6efd; }
}
@layer custom {
  .btn-primary { background-color: #7c3aed; }  /* Always wins */
}

Third-Party Widget CSS

Embedded widgets (chat plugins, payment forms, social embeds) often inject highly specific CSS. Strategies for overriding:

/* Third-party widget uses highly specific selectors */
/* e.g., #chat-widget .chat-container .message-bubble { color: black; } */
/* Specificity: (1,2,0) */

/* Strategy 1: Match or exceed their specificity */
#chat-widget .chat-container .message-bubble {
  color: white;  /* (1,2,0) — same specificity, your CSS loads later */
}

/* Strategy 2: Use !important as last resort */
.message-bubble {
  color: white !important;  /* Overrides non-!important rules */
}

/* Strategy 3: Shadow DOM encapsulation (for your own widgets) */
/* Styles inside shadow DOM don't compete with outer specificity */

/* Strategy 4: @layer the third-party CSS */
@layer vendor, custom;

@layer vendor {
  @import url('third-party-widget.css');
}
@layer custom {
  .message-bubble { color: white; }  /* Layer priority wins */
}

Specificity in CSS-in-JS

Libraries like styled-components and Emotion generate unique class names with specificity (0,1,0). When these conflict with global styles:

/* styled-components generates: .sc-abc123 { color: blue; } */
/* Specificity: (0,1,0) */

/* Global style that might conflict */
p { color: black; }  /* (0,0,1) — styled-component wins */

/* But if global CSS uses a class: */
.dark-theme p { color: white; }  /* (0,1,1) — beats styled-component */

/* Solution: Use && to double specificity in styled-components */
const Button = styled.button`
  && {
    color: blue;  /* Generates .sc-abc123.sc-abc123 → (0,2,0) */
  }
`;

/* Solution: Use @layer for global styles */
@layer globals;

@layer globals {
  .dark-theme p { color: white; }
}
/* styled-components (unlayered) will win over layered globals */

Dark Mode Toggle Battles

Dark mode implementations often create specificity issues when theme selectors compete with component selectors:

/* Common dark mode specificity issue */
.card { background: white; color: #333; }  /* (0,1,0) */

/* Dark mode with attribute selector */
[data-theme="dark"] .card {
  background: #1a1a2e; color: #e0e0e0;    /* (0,2,0) */
}

/* Now a modifier class cannot override dark mode! */
.card.highlighted {
  background: yellow;  /* (0,2,0) — TIES with dark mode */
  /* Winner depends on source order — fragile! */
}

/* SOLUTION: Use consistent nesting depth */
[data-theme="dark"] .card.highlighted {
  background: #ffd700;  /* (0,3,0) — reliably wins */
}

/* BETTER SOLUTION: Use CSS custom properties */
:root {
  --card-bg: white;
  --card-color: #333;
}
[data-theme="dark"] {
  --card-bg: #1a1a2e;
  --card-color: #e0e0e0;
}
.card {
  background: var(--card-bg);
  color: var(--card-color);
}
.card.highlighted {
  --card-bg: yellow;  /* Works in both themes! */
}
[data-theme="dark"] .card.highlighted {
  --card-bg: #ffd700;
}

11. Best Practices for Managing Specificity

Follow these proven strategies to keep specificity manageable across projects of any size:

BEM Methodology

BEM (Block, Element, Modifier) keeps specificity flat by using single-class selectors. Every selector has specificity (0,1,0).

/* BEM: flat specificity — every selector is (0,1,0) */

/* Block */
.card { padding: 16px; border: 1px solid #ddd; }

/* Element (block__element) */
.card__title { font-size: 1.5rem; font-weight: bold; }
.card__body { padding: 8px 0; }
.card__footer { border-top: 1px solid #eee; }

/* Modifier (block--modifier) */
.card--featured { border-color: gold; }
.card--compact { padding: 8px; }

/* Element + Modifier */
.card__title--large { font-size: 2rem; }

/* All selectors have specificity (0,1,0) — no conflicts!
   Override order is controlled purely by source order. */

Avoid Deep Nesting

Deeply nested selectors create high specificity and fragile styles. Keep your selector depth to a maximum of 3 levels.

/* BAD: Deep nesting creates high specificity */
/* Specificity: (0,0,6) — hard to override */
header nav ul li a span {
  color: blue;
}

/* BAD: Nesting with classes makes it worse */
/* Specificity: (1,3,2) — very hard to override */
#page .header .nav-container ul.menu li.active a {
  color: red;
}

/* GOOD: Flat, single-class selectors */
/* Specificity: (0,1,0) — easy to override */
.nav-link {
  color: blue;
}

.nav-link--active {
  color: red;
}

/* ACCEPTABLE: Maximum 3 levels when truly needed */
/* Specificity: (0,2,0) */
.nav .nav-link {
  color: blue;
}

Utility-First Approach

Utility-first CSS (Tailwind, UnoCSS) avoids specificity issues entirely by applying single-purpose classes directly in HTML. Every utility has specificity (0,1,0), and ordering is controlled by the stylesheet generation order.

<!-- Utility-first: all specificity is (0,1,0) -->
<div class="flex items-center gap-4 p-4 bg-white rounded-lg shadow-md">
  <img class="w-12 h-12 rounded-full" src="avatar.jpg" alt="Avatar" />
  <div>
    <h3 class="text-lg font-semibold text-gray-900">Jane Doe</h3>
    <p class="text-sm text-gray-500">Software Engineer</p>
  </div>
</div>

<!-- No specificity conflicts because:
  1. Each utility = one class = (0,1,0)
  2. Order is determined by the stylesheet, not HTML
  3. No nesting, no IDs, no !important needed -->

<!-- Tailwind important mode (adds !important to all utilities) -->
<!-- tailwind.config.js: { important: true } -->
<!-- .text-red-500 { color: #ef4444 !important; } -->

Use Cascade Layers

Organize your CSS into layers to create predictable override behavior without increasing specificity:

/* Recommended layer structure for large projects */
@layer reset, base, tokens, components, layouts, utilities, overrides;

@layer reset {
  /* CSS reset / normalize — :where() for zero specificity */
  :where(*, *::before, *::after) { box-sizing: border-box; margin: 0; }
  :where(body) { line-height: 1.5; }
}

@layer base {
  /* Base element styles */
  :where(h1) { font-size: 2.5rem; }
  :where(a) { color: var(--color-link); }
}

@layer tokens {
  /* Design tokens / CSS variables */
  :root { --color-primary: #3b82f6; --color-link: #2563eb; }
  [data-theme="dark"] { --color-primary: #60a5fa; --color-link: #93c5fd; }
}

@layer components {
  /* Component styles */
  .btn { padding: 8px 16px; background: var(--color-primary); }
  .card { padding: 16px; border-radius: 8px; }
}

@layer utilities {
  /* Utility overrides */
  .text-center { text-align: center; }
  .hidden { display: none; }
}

@layer overrides {
  /* Third-party overrides, edge cases */
}

Specificity Audit Checklist

  • Avoid ID selectors in stylesheets — use classes instead.
  • Keep selector depth to 3 or fewer levels.
  • Never use !important unless in a utility class or for third-party overrides.
  • Use :where() for base/reset styles.
  • Use cascade layers (@layer) for large projects.
  • Prefer single-class selectors (BEM pattern).
  • Use your browser DevTools specificity indicators to debug conflicts.

12. Frequently Asked Questions

How is CSS specificity calculated?

CSS specificity is calculated as a tuple (a, b, c): count the number of ID selectors (a), class selectors, attribute selectors, and pseudo-classes (b), and element selectors and pseudo-elements (c). Compare from left to right — a higher number in an earlier position always wins. For example, one ID selector (1,0,0) beats any number of class selectors (0,n,0).

Does !important override specificity?

Yes, !important overrides normal specificity entirely. A rule with !important beats any rule without it, regardless of selector specificity. However, when two rules both have !important, the normal specificity comparison applies between them. Cascade layers add another dimension: !important in an earlier layer beats !important in a later layer.

What is the specificity of :where() vs :is()?

:where() always has zero specificity, regardless of its arguments. :is() takes the specificity of its most specific argument. For example, :where(#id, .class) has specificity (0,0,0), while :is(#id, .class) has specificity (1,0,0) because the #id argument has the highest specificity among its arguments.

Can 256 classes override one ID selector?

No. This is a common myth. In all modern browsers, specificity categories do not overflow into each other. No number of class selectors can ever override a single ID selector. The (a,b,c) values are compared independently from left to right, not as a single concatenated number. Older browsers (IE6 era) had a bug where 256 classes could overflow, but this has not been the case since approximately 2012.

How do cascade layers affect specificity?

Cascade layers (@layer) introduce a priority system that sits above specificity in the cascade. Styles in a higher-priority layer always win over styles in a lower-priority layer, regardless of specificity. Within the same layer, normal specificity rules apply. Unlayered styles beat all layered styles. For !important rules, the order reverses: earlier layers beat later layers.

Mastering CSS specificity is fundamental to writing clean, predictable stylesheets. Use flat selectors, avoid IDs in CSS, leverage cascade layers and :where() for override control, and reserve !important for true edge cases. With these principles, specificity battles become a thing of the past.

Minify and optimize your CSS with our CSS Minifier →

Browse Tailwind color palettes with our Tailwind Colors tool →

𝕏 Twitterin LinkedIn
¿Fue útil?

Mantente actualizado

Recibe consejos de desarrollo y nuevas herramientas.

Sin spam. Cancela cuando quieras.

Prueba estas herramientas relacionadas

{ }CSS Minifier / BeautifierTWTailwind CSS Color PickerTWCSS to Tailwind

Artículos relacionados

Hoja de referencia CSS Flexbox: Cada propiedad explicada con ejemplos

Hoja de referencia visual CSS Flexbox con todas las propiedades y ejemplos.

Variables CSS (Propiedades personalizadas): Guía completa

Domina las propiedades personalizadas CSS. Sintaxis, alcance, valores de respaldo, temas oscuros y actualizaciones dinámicas.