14 Css Overview

Chrome DevTools — CSS Overview Panel

---

What the CSS Overview Panel Is

The CSS Overview panel is a one-shot audit tool built into Chrome DevTools that takes a complete snapshot of every style rule, color, font, media query, and unused declaration present on the currently loaded page. Unlike the Styles pane (which shows styles for a single selected element) or the Coverage tool (which tracks line-level usage during interaction), CSS Overview scans the entire document at capture time and produces a structured report across five categories.

Think of it as a static “X-ray” of your stylesheet health:

Category	What it answers
Overview Summary	How many elements, stylesheets, and inline styles exist?
Colors	Which colors are used? Are any combinations failing contrast?
Font Info	Which typefaces, sizes, weights, and line heights appear?
Unused Declarations	Which CSS properties are declared but never applied?
Media Queries	Which breakpoints and feature queries exist across all sheets?

CSS Overview is especially valuable before a refactor, during a design system audit, or when preparing an accessibility report — situations where you need a high-level inventory rather than element-by-element investigation.

---

How to Open the CSS Overview Panel

Method 1 — More Tools menu (most reliable)

1. Open DevTools with F12 / Cmd+Option+I / Ctrl+Shift+I.
2. Click the vertical ellipsis (...) in the DevTools toolbar (top-right).
3. Hover More tools.
4. Click CSS Overview.

The panel opens as a new tab inside DevTools.

Method 2 — Command Menu

1. Open DevTools.
2. Press Cmd+Shift+P (Mac) / Ctrl+Shift+P (Windows/Linux).
3. Type CSS Overview and select Show CSS Overview.

Method 3 — Persistent tab (after first open)

Once opened, the CSS Overview tab persists in the DevTools tab bar for the remainder of the DevTools session. You can click directly on it next time without going through the menu.

---

UI Layout

The panel has two distinct states: the welcome screen (before capture) and the report view (after capture).

Welcome screen

+--------------------------------------------------------------+
|  DevTools  [Elements] [Console] [Sources] ... [CSS Overview] |
+--------------------------------------------------------------+
|                                                              |
|   CSS Overview                                               |
|                                                              |
|   Take a snapshot of your page's CSS to identify potential   |
|   CSS improvements.                                          |
|                                                              |
|            [ Capture overview ]                              |
|                                                              |
+--------------------------------------------------------------+

Report view (after capture)

+---------------------------------------------------------------+
| CSS Overview                          [ Capture overview ]    |
+---------------------------+-----------------------------------+
|  NAVIGATION SIDEBAR       |  DETAIL PANE                      |
|                           |                                   |
|  > Overview summary       |  (content of selected section)    |
|  > Colors                 |                                   |
|  > Font info              |                                   |
|  > Unused declarations    |                                   |
|  > Media queries          |                                   |
|                           |                                   |
+---------------------------+-----------------------------------+

The left sidebar is a fixed navigation list. Clicking any item replaces the right pane with that section’s data. The Capture overview button in the top-right re-runs the audit without closing the current results — useful for comparing before/after a live edit.

---

Running a CSS Overview Capture

What triggers a capture

Clicking Capture overview causes DevTools to:

1. Enumerate every <link rel="stylesheet"> and <style> element in the document.
2. Parse all rules from document.styleSheets — including cross-origin sheets that have CORS headers, but excluding blocked sheets (see Limitations).
3. Walk the entire DOM (document.querySelectorAll('*')) and resolve computed styles for each element.
4. Cross-reference declared properties against computed/resolved values to identify unused declarations.
5. Collect all @media rules across every stylesheet.
6. Snapshot all color values (foreground and background) and compute contrast ratios for text nodes.

What is analyzed

Analyzed	Not analyzed
External stylesheets with CORS headers	Cross-origin sheets without CORS headers
Inline <style> blocks	Styles injected after capture (e.g., lazy-loaded CSS)
style="" inline attributes	Styles from Shadow DOM (not pierced)
CSS custom properties (as values)	JavaScript-set styles that haven’t been applied yet
@media, @supports, @layer rules	CSS Houdini Paint Worklet styles

Capture timing matters

CSS Overview captures the page state at the moment you click the button. If your page dynamically adds classes (e.g., after a user interaction), those styles may not appear in the unused declarations list even if they are declared in a stylesheet. Always capture after fully loading the page and, if possible, after triggering the most common UI states.

---

The Five Report Sections

---

1. Overview Summary

The summary tab is the landing view immediately after capture. It presents a row of counters:

+-------------------------------------------------------+
|  Overview summary                                     |
|                                                       |
|  Elements               1,204                         |
|  Stylesheets                8                         |
|  Inline style elements      3                         |
|  External stylesheets        5                         |
|  Type selectors            42                         |
|  ID selectors               7                         |
|  Class selectors          318                         |
|  Universal selectors         2                         |
|  Attribute selectors        11                         |
|  Non-simple selectors       89                         |
+-------------------------------------------------------+

What each counter means:

Counter	Meaning	Red flag threshold
Elements	Total DOM nodes captured	Very high counts slow style recalculation
Stylesheets	Total stylesheet objects (inline + external)	More than ~10-15 warrants consolidation
Inline style elements	<style> blocks in the HTML	Non-zero in a component app often means un-extracted CSS-in-JS
External stylesheets	<link rel="stylesheet"> count	Each is a render-blocking request
ID selectors	Rules using #id	Any non-zero count in a component system is a specificity smell
Non-simple selectors	Selectors with more than one component	High counts → specificity wars

Actionable takeaway: Use the summary to set a baseline before a refactor and compare after. If external stylesheets drop from 8 to 3 after bundling, the summary proves it.

---

2. Colors

The Colors section displays every unique color value found across all stylesheets, organized by type:

• Background colors — used as background, background-color
• Text colors — used as color
• Fill colors — used as SVG fill
• Border colors — used as border-color, border-top-color, etc.

Each color appears as a swatch with its CSS value underneath.

Contrast ratio warnings

Text/background color pairs that fall below WCAG thresholds are flagged with a warning indicator directly on the swatch:

WCAG Level	Minimum ratio (normal text)	Minimum ratio (large text >= 18pt or 14pt bold)
AA	4.5 : 1	3 : 1
AAA	7 : 1	4.5 : 1

A warning badge appears on any color swatch that participates in a failing pair. Hovering the badge shows the exact computed ratio and which element triggered it.

Clicking a color swatch

Clicking any color swatch switches the detail pane to show a list of every element that uses that color. Each row is an interactive link — clicking a row:

1. Switches to the Elements panel.
2. Selects that DOM node.
3. Scrolls the page viewport to reveal the element.

This makes it trivial to audit “which elements are using this off-brand hex?” without writing a single line of JavaScript.

---

3. Font Info

The Font Info section builds a complete inventory of every font variation in use. It groups entries by font family, and within each family lists every distinct combination of:

• Font size
• Font weight
• Line height

Example layout:

Inter
  └── 12px / 400 / 1.5      (used by 34 elements)
  └── 14px / 400 / 1.5      (used by 128 elements)
  └── 14px / 600 / 1.4      (used by 22 elements)
  └── 16px / 400 / 1.6      (used by 19 elements)
  └── 24px / 700 / 1.2      (used by 8 elements)
  └── 32px / 700 / 1.1      (used by 3 elements)

Georgia
  └── 16px / 400 / 1.7      (used by 2 elements)

Clicking a font variation

Clicking any font variation row (e.g., “14px / 400 / 1.5”) shows the list of matching elements in the detail pane — same drill-down behavior as the Colors section.

Identifying font inconsistencies

A well-maintained design system typically has:

• 1–2 font families
• A defined scale of sizes (e.g., 12, 14, 16, 20, 24, 32, 48px)
• 2–4 weights
• 1–2 line heights

If the Font Info panel shows 47 distinct size values, 6 font families, or weights like 450 and 550, those are signals that typography has drifted from a spec and needs consolidation.

---

4. Unused Declarations

This section lists CSS property declarations that were found in stylesheets but that did not resolve to any currently rendered element at capture time.

Sample output

.hero-cta-old { display: flex }          -- no matching element
.modal--v2 { opacity: 0 }               -- no matching element
.sidebar .widget-title { font-size: 11px } -- no matching element
@media print { body { font-size: 10pt } } -- no matching element

Each row shows the full selector, the property, and the value.

What counts as “unused”

A declaration is flagged as unused when:

1. The CSS selector matches zero elements in the current DOM at the time of capture.
2. OR the selector matches elements but the property is overridden by a higher-specificity rule at every matched element.

Common sources of unused declarations

Source	Example	Action
Dead code / removed components	.carousel--legacy { ... }	Delete if component is gone
Responsive styles not triggered	@media (max-width: 480px) { ... } at desktop width	Capture again at mobile viewport
Print stylesheets	@media print { ... }	Evaluate: still needed?
A/B test remnants	.cta-variant-b { ... }	Delete if experiment concluded
JavaScript-controlled classes	.is-active { ... }	Requires interaction before capture; see Limitations

Limitations — dynamic classes

CSS Overview takes a single snapshot. If a class like .dropdown--open only exists on an element when a dropdown is expanded, and the dropdown was closed at capture time, the rule will appear as “unused” even though it is actively used. Always:

1. Expand all interactive states before capturing for the most accurate unused list.
2. Cross-reference findings with the Coverage tool (see section below) for interaction-based usage.

---

5. Media Queries

The Media Queries section lists every @media rule found across all stylesheets, grouped by type:

• max-width breakpoints
• min-width breakpoints
• print queries
• prefers-color-scheme
• prefers-reduced-motion
• orientation
• hover / pointer feature queries
• Custom / other

Each entry shows the full query string and how many declarations are inside it.

Example

Media Queries (23 found)

  max-width
    @media (max-width: 1280px)   --  42 declarations
    @media (max-width: 1024px)   --  17 declarations
    @media (max-width: 768px)    --  89 declarations
    @media (max-width: 480px)    --  61 declarations
    @media (max-width: 375px)    --   8 declarations

  min-width
    @media (min-width: 768px)    --  34 declarations
    @media (min-width: 1024px)   --  22 declarations

  prefers-color-scheme
    @media (prefers-color-scheme: dark)  --  118 declarations

  prefers-reduced-motion
    @media (prefers-reduced-motion: reduce)  --  12 declarations

  print
    @media print                 --  28 declarations

Why this view is valuable

Seeing all breakpoints in one list instantly reveals:

• Inconsistent breakpoint values (e.g., 768px and 769px both appear — a common copy-paste bug).
• Missing accessibility queries (prefers-reduced-motion absent on an animation-heavy page).
• Redundant breakpoints that could be consolidated.
• Whether mobile-first (min-width) or desktop-first (max-width) patterns are mixed.

---

Colors Section — Deep Dive

Accessibility: finding low-contrast text

The primary accessibility use case for CSS Overview is identifying text/background pairs that fail WCAG contrast requirements before a formal accessibility audit.

Workflow:

1. Load the page fully (all fonts, images, lazy content).
2. Open CSS Overview and capture.
3. Navigate to Colors.
4. Look for swatches with a warning indicator (a small icon or badge).
5. Click the warning to see which element pairs triggered it.
6. Note the exact ratio (e.g., 2.8:1) and the elements involved.
7. Switch to Elements panel, select the element, and adjust color or background-color in the Styles pane until the ratio meets 4.5:1.

Contrast ratio reference:

Ratio    WCAG AA normal text    WCAG AA large text    WCAG AAA
< 3.0:1  FAIL                   FAIL                  FAIL
3.0:1    FAIL                   PASS                  FAIL
4.5:1    PASS                   PASS                  FAIL
7.0:1    PASS                   PASS                  PASS

Color inventory — spotting off-brand colors

Every serious design system defines a palette (often as CSS custom properties or design tokens). CSS Overview lets you compare the actual colors in use against that palette:

1. Capture the overview.
2. Navigate to Colors > Text colors.
3. Look for hex values that are not in your design token set.

Example: your brand allows only #1A1A2E, #16213E, #0F3460, #E94560 as text colors. If the Colors panel shows #333333, #444, and #1b1b1b scattered around, those are off-brand drifts.

Pro tip: Copy the full color list by right-clicking a swatch area — some DevTools versions allow copying values. Alternatively, run this in the Console after a capture to dump all colors to clipboard-friendly text:

// Not a DevTools API — use the panel's visual list for accuracy
// But you can cross-check with:
[...document.querySelectorAll('*')]
  .map(el => getComputedStyle(el).color)
  .filter((v, i, a) => a.indexOf(v) === i)
  .sort()
  .forEach(c => console.log(c));

Clicking a color to trace element usage

This drill-down feature turns CSS Overview from a passive audit into an interactive investigation tool:

1. In the Colors panel, click any color swatch (e.g., a suspicious rgb(255, 0, 128)).
2. The detail pane updates to a list of every element using that color.
3. Click any element row to jump directly to it in the Elements panel.
4. The page viewport scrolls to reveal the element.
5. The Styles pane on the right shows exactly which rule is setting that color.

This is far faster than running document.querySelectorAll('[style*="color"]') and manually inspecting each result.

Identifying color inconsistencies

Signs of color inconsistency in the Colors panel:

Symptom	Likely cause
Multiple near-identical grays (#333, #333333, rgb(51,51,51))	Different notation for the same color — consolidate to one token
Both rgba(0,0,0,0.87) and #212121 in use	Mixed material design / custom styles
20+ distinct blue values	No design token enforcement; every developer guessed
Colors from a third-party component library appearing	Vendor CSS leaking into your token set

---

Font Section — Deep Dive

Font inventory methodology

Before a typography refactor, use the Font Info section to build an exact census:

1. Capture the overview on your most representative page.
2. Capture again on 2–3 other key pages (product, checkout, blog post).
3. Compare the font family lists across captures (re-capture after navigating to each page).
4. Document every unique font family found — this becomes your “fonts in use” list.

Clicking to see which elements use a specific font/size/weight

1. In Font info, click a font family name to expand it.
2. Click a specific variation row (e.g., 14px / 400 / 1.5).
3. The right pane shows every element using that exact combination.
4. Click an element row to select it in Elements.

This is the fastest way to answer “which elements are using 13px text?” — a common question when auditing for minimum font size accessibility (WCAG recommends avoiding text below 9px, but many teams enforce a higher floor like 12px or 14px).

Identifying font inconsistencies — practical thresholds

Variation type	Healthy count	Warning threshold	Action
Font families	1–2	4+	Audit for accidental system-font fallbacks, vendor fonts
Distinct font sizes	6–10	15+	Map to a type scale, replace one-offs with nearest token
Distinct weights	2–4	6+	Check if weights are actually loading; some may be browser-synthesized
Distinct line heights	2–4	8+	Consolidate to a ratio-based scale (e.g., 1.2, 1.4, 1.6)

Catching synthesized fonts

When a weight like font-weight: 800 is used but the font file for that weight was never loaded, the browser synthesizes bold by algorithmically thickening the letterforms. This looks noticeably different from a real weight. The Font Info panel shows you which weights are declared — cross-reference against your @font-face rules or CDN font load parameters to confirm all declared weights are actually loaded.

---

Unused Declarations — Deep Dive

Step-by-step audit workflow

1. Deploy / load the page in a production-like state
2. Trigger common interactions (open modals, expand accordions, activate hover states)
3. Open CSS Overview -> Capture overview
4. Navigate to Unused declarations
5. Export / screenshot the list
6. For each declaration, ask:
   a. Is this selector used anywhere in the app? (Search codebase)
   b. Is it only active in a state not triggered at capture? (Dynamic class)
   c. Is it a responsive rule that needs a different viewport? (Capture at that viewport)
   d. Is it vendor-prefixed and redundant? (e.g., -webkit- with unprefixed version)
7. For confirmed dead code, delete from the source stylesheet
8. Re-capture and verify the declaration no longer appears

Vendor prefix bloat

A common source of “unused” declarations is obsolete vendor prefixes:

/* The -webkit- and -moz- versions below will appear as unused on modern Chrome */
.box {
  -webkit-border-radius: 8px;  /* unused — Chrome doesn't need this */
  -moz-border-radius: 8px;     /* unused — Firefox dropped this in v4 */
  border-radius: 8px;          /* used */
}

.flex-container {
  display: -webkit-box;        /* unused */
  display: -ms-flexbox;        /* unused */
  display: flex;               /* used */
}

Unused declarations from vendor prefixes are safe to remove if your browser support matrix no longer includes the affected browsers. Check caniuse.com for the property’s unprefixed support threshold.

Responsive declarations — capture at multiple viewports

CSS Overview is viewport-aware: rules inside @media (max-width: 768px) will appear unused when captured at 1440px. To fully audit responsive styles:

1. Open Chrome DevTools.
2. Toggle Device Toolbar (Cmd+Shift+M / Ctrl+Shift+M).
3. Set viewport to 375px (mobile).
4. Reload the page.
5. Open CSS Overview and capture.
6. Compare the Unused Declarations list with the desktop capture.
7. Rules that are “used” at mobile but “unused” at desktop are correctly responsive — do not delete them.

Distinguishing dead code from dynamic classes

Scenario	Appears unused?	Is it safe to delete?
.hero-cta-v1 — old component removed from HTML	Yes	Yes — confirm in codebase search
.modal--open — class added by JS when modal opens	Yes (if modal closed at capture)	No — verify usage in JS
.theme--dark — class toggled by user preference	Yes (if not active at capture)	No — trigger the state and recapture
@media print { ... } — print styles	Yes (screen capture)	Only if print support is explicitly dropped
.sr-only — screen-reader-only visually hidden text	Maybe (zero dimensions)	No — critical for accessibility

---

Media Queries Overview — Deep Dive

Spotting breakpoint inconsistencies

A clean responsive system has a small, consistent set of breakpoints, usually defined as variables or tokens. CSS Overview’s Media Queries section makes inconsistencies obvious:

Problematic pattern:

@media (max-width: 768px)
@media (max-width: 767px)
@media (max-width: 769px)
@media (min-width: 768px)
@media (min-width: 769px)

These five rules all target roughly the same breakpoint with off-by-one values, which creates unpredictable behavior in the 767–769px range. A single source-of-truth breakpoint variable eliminates this.

Healthy pattern:

// Single source of truth
$bp-md: 768px;

// Used consistently
@media (max-width: $bp-md) { ... }
@media (min-width: #{$bp-md + 1px}) { ... }

Checking for accessibility media queries

CSS Overview makes it easy to verify that your stylesheet respects user preferences:

Query	What it means	Check with CSS Overview
prefers-reduced-motion	User has requested less animation	Should appear if you have any transitions/animations
prefers-color-scheme: dark	User prefers dark UI	Should appear if you support dark mode
prefers-contrast: high	User needs higher contrast	Bonus accessibility support
forced-colors	Windows High Contrast mode	Advanced accessibility support

If your page has animations but prefers-reduced-motion does not appear in the Media Queries list, that is an accessibility gap.

Mobile-first vs desktop-first audit

Count the min-width vs max-width entries:

• Mostly min-width → mobile-first (generally preferred, better cascade performance)
• Mostly max-width → desktop-first (older pattern, more specificity overrides needed)
• Mix of both → fragmented stylesheet from multiple eras of development

---

Practical Use Cases

Use case 1: CSS audit before a refactor

Scenario: You are about to consolidate three legacy CSS files into a new design-system-backed stylesheet.

Steps:

1. Capture CSS Overview on the production site.
2. Record baseline numbers from the Summary tab (elements, stylesheets, selectors).
3. Export/screenshot the Colors and Font Info sections.
4. Note all external stylesheets from the Summary (these should reduce after refactor).
5. Complete the refactor.
6. Capture again on staging.
7. Compare: fewer stylesheets, fewer color values, fewer font variations, fewer unused declarations.

The before/after comparison is your objective proof that the refactor improved CSS health.

---

Use case 2: Design system enforcement

Scenario: Your design system defines 12 colors and 3 font weights. You want to enforce that no page uses colors or weights outside this set.

Steps:

1. Capture CSS Overview.
2. Open the Colors section.
3. Look for any color not in your approved palette.
4. Click each off-palette color to identify the element.
5. Navigate to source and replace with the correct design token.
6. Repeat for Font Info → check weights for anything outside 400, 600, 700.

Automation note: For continuous enforcement, this manual process can be augmented with a CSS linting rule (e.g., Stylelint’s declaration-property-value-allowed-list) that rejects non-token values at commit time.

---

Use case 3: Accessibility audit — finding low-contrast text

Scenario: You need to produce a WCAG AA accessibility compliance report for your marketing site.

Steps:

1. Load the page with all content visible (no spinner, no lazy states).
2. Capture CSS Overview.
3. Navigate to Colors.
4. Identify all swatches with contrast warnings.
5. For each warning:
   • Note the color pair.
   • Note the elements affected.
   • Calculate the required color adjustment (darken foreground or lighten background).
6. Apply fixes in DevTools Styles pane, screenshot the corrected ratio.
7. Write fixes to the source stylesheet.
8. Re-capture to verify warnings are resolved.

This produces a documented audit trail: original colors, failing ratios, corrected colors, passing ratios.

---

Use case 4: Identifying CSS bloat

Scenario: Your CSS bundle is 420 KB uncompressed. You want to understand what is in it.

Steps:

1. Capture CSS Overview.
2. Check the Summary:
   • How many external stylesheets? Each one is overhead.
   • How many selectors? High counts suggest un-purged utility class frameworks (e.g., full Tailwind without PurgeCSS).
3. Check Unused Declarations: a very long list indicates large amounts of dead CSS.
4. Check Media Queries: many redundant breakpoints suggest duplicated responsive code.
5. Use findings to prioritize: remove dead code first (Unused Declarations), then consolidate breakpoints, then remove vendor prefix bloat.

---

Combining CSS Overview with the Coverage Tool

CSS Overview and the Coverage tool answer different but complementary questions:

Tool	Question answered	Granularity	Interaction-aware?
CSS Overview	Which declarations match zero elements?	Declaration level	No (snapshot)
Coverage	Which CSS lines were applied during a session?	Line level	Yes (records during use)

When to use which

• Use CSS Overview Unused Declarations for a quick structural audit at page load — it finds orphaned selectors fast.
• Use Coverage when you need to account for dynamic states, hover effects, and JavaScript-driven classes — record a full user session.
• Use both together for comprehensive analysis: anything flagged by CSS Overview AND uncovered by Coverage is almost certainly dead code.

Combined workflow

1. Open CSS Overview
2. Capture → note Unused Declarations list (call this set A)

3. Open Coverage (DevTools > More tools > Coverage)
4. Click the record button
5. Perform a realistic user session:
   - Navigate all major pages
   - Open all modals and drawers
   - Activate all hover and focus states
   - Switch themes if applicable
6. Stop recording
7. Review Coverage results — lines shown in red are never-executed CSS (call this set B)

8. Intersection of A and B = high-confidence dead CSS
   - Safe to remove without thorough manual review
9. Items in B but not A = CSS that is declared but only triggered by interaction
   - Review carefully before removing

Reading Coverage results alongside CSS Overview

In the Coverage panel, each stylesheet row shows:

main.css     124 KB     34% used     82 KB unused
vendor.css    88 KB     12% used     77 KB unused

If vendor.css is 88% unused, that is a strong signal to either:

• Tree-shake the vendor library (e.g., enable Tailwind’s purge/content config).
• Replace the vendor library with hand-written styles covering only the used subset.
• Load it conditionally per page rather than globally.

---

Advanced: Using CSS Overview Findings to Inform a Design Token Migration

What is a design token migration?

A design token migration replaces hardcoded CSS values (colors, sizes, fonts) with semantic variable references:

/* Before migration — hardcoded values */
.button-primary {
  background-color: #0F3460;
  color: #FFFFFF;
  font-size: 14px;
  font-weight: 600;
  border-radius: 4px;
}

/* After migration — token references */
.button-primary {
  background-color: var(--color-brand-primary);
  color: var(--color-text-on-brand);
  font-size: var(--font-size-sm);
  font-weight: var(--font-weight-semibold);
  border-radius: var(--radius-sm);
}

Phase 1: Discovery using CSS Overview

Before writing a single token, use CSS Overview to build an exhaustive inventory.

Color token discovery:

1. Capture CSS Overview on all representative pages.
2. Open Colors → Background colors. List every distinct value.
3. Open Colors → Text colors. List every distinct value.
4. Open Colors → Border colors. List every distinct value.
5. Group similar values (e.g., 8 variants of blue → 2–3 semantic token slots).

Font token discovery:

1. Open Font info.
2. List every distinct font size → these become your --font-size-* scale.
3. List every distinct weight → these become --font-weight-* tokens.
4. List every distinct line height → these become --line-height-* tokens.
5. Identify the most-used combinations → these become composite typography tokens.

Sample token map derived from CSS Overview:

Observed value	Frequency	Proposed token
#0F3460	42 uses	--color-brand-primary
#E94560	18 uses	--color-brand-accent
#FFFFFF	93 uses	--color-surface-base
#F5F5F5	27 uses	--color-surface-subtle
#1A1A2E	61 uses	--color-text-primary
14px	128 uses	--font-size-sm
16px	89 uses	--font-size-base
24px	31 uses	--font-size-lg
400	204 uses	--font-weight-regular
600	67 uses	--font-weight-semibold

Phase 2: Consolidation decisions

CSS Overview’s frequency counts guide consolidation:

• Colors appearing only 1–2 times are candidates for elimination (replace with nearest token).
• Font sizes appearing only 1–3 times are one-off deviations to eliminate.
• Weights not in your font file’s supported set are synthesized and should be standardized.

Phase 3: Migration and verification

After replacing hardcoded values with tokens:

1. Re-capture CSS Overview.
2. Colors section: the inventory should now show only a small set of var(--...) based values OR the token values themselves used consistently.
3. Font info: the variation count should drop dramatically.
4. Unused Declarations: if you removed one-off styles during the migration, this list should shrink.
5. The Summary’s selector count may decrease if you consolidated duplicate rules.

Phase 4: Ongoing governance

CSS Overview is a point-in-time tool, but the findings drive permanent process improvements:

CSS Overview finding          →    Process response
─────────────────────────────────────────────────────────────
Off-brand colors found        →    Stylelint: color-no-invalid-hex + allowed-list
Too many font sizes           →    Stylelint: declaration-property-value-allowed-list
Unused declarations growing   →    PurgeCSS / Tailwind content config + CI check
Breakpoint inconsistencies    →    PostCSS custom media + single breakpoint file
Missing prefers-reduced-motion →    PR checklist item for animation authors

---

Quick Reference Card

Open CSS Overview

DevTools → ... (More tools) → CSS Overview
  OR
Cmd+Shift+P → "CSS Overview"

Capture

Click "Capture overview" button (top-right of panel)
Re-capture at any time to refresh

Section cheat sheet

Section	Primary use	Click behavior
Overview summary	Baselines, stylesheet count	No drill-down
Colors	Contrast audit, off-brand colors	Click swatch → elements using it
Font info	Typography audit, scale enforcement	Click variation → elements using it
Unused declarations	Dead CSS identification	Click rule → Elements panel
Media queries	Breakpoint audit, a11y queries	No drill-down (list only)

What CSS Overview does NOT do

• It does not track changes over time (no historical data).
• It does not analyze cross-origin stylesheets without CORS headers.
• It does not reflect styles added after capture (dynamic JS injection).
• It does not pierce Shadow DOM.
• It does not replace the Coverage tool for interaction-driven CSS analysis.

---

Summary

The CSS Overview panel is the fastest way to get a structural health report on the CSS of any web page. Its five sections address the four most common CSS maintenance problems: color inconsistency, typography drift, dead code, and breakpoint fragmentation. The contrast ratio warnings make it a practical first step in any accessibility audit. The drill-down from any color or font value directly to the element using it turns abstract inventory data into actionable investigation.

For teams managing a design system, running CSS Overview on a regular cadence (before each major release, or as part of a quarterly CSS audit) surfaces drift early — before it compounds into a months-long refactor. Combined with the Coverage tool and a linting setup derived from the token map it helps you build, CSS Overview becomes the foundation of a sustainable CSS quality process.

---

← Web Devtools