WordPress 7.1 Adds Text Shadow to Global Styles

Every couple of years the block editor picks up a small typography feature that has been missing so long you had forgotten to ask for it. Text shadow is one of those. On paper it is a one-line CSS property. In WordPress theme land it has been three years of half-solutions — a bit of custom CSS in a child theme, a plugin for one heading, a snippet copy-pasted into additional CSS until nobody remembers where the shadow on the hero comes from.

I keep saying WordPress wins the long game because of maturity — redirections, revisions, plugin ecosystem, a governance layer that scales. Global Styles is the design-system version of that story. Every time a real design token moves from CSS snippets into theme.json, the site becomes a little easier to hand off, a little cheaper to keep, a little less dependent on the one developer who wrote the shadow rule in 2023.

WordPress 7.1 adds text shadow to that layer. Not as a plugin, not as a filter, not as another block. A first-class property under styles.typography, defined once in theme.json, applied globally or per block or per element state. Here is what it does, what it does not do yet, and where I would use it this month.

What is actually new

The dev note “Text Shadow Support in Global Styles” by Aaron Robertshaw landed on Make/Core on July 23, 2026. It documents the surface that ships in WordPress 7.1 (GA August 19, per the release party schedule) and is already frozen inside Beta 3.

The mechanism is a new textShadow property under styles.typography. It maps straight to the CSS text-shadow property, so any valid CSS value works — single shadow, multiple comma-separated shadows, whatever your designer sketches in Figma. It can be set at three levels: global typography, per block (styles.blocks.core/paragraph.typography), and per element including states (styles.elements.link.:hover.typography).

{
  "styles": {
    "typography": {
      "textShadow": "1px 1px 2px red, 0 0 1em blue, 0 0 0.2em blue"
    },
    "blocks": {
      "core/paragraph": {
        "typography": {
          "textShadow": "1px 1px 2px red, 0 0 1em red, 0 0 0.2em red"
        }
      }
    },
    "elements": {
      "link": {
        ":hover": {
          "typography": {
            "textShadow": "none"
          }
        }
      }
    }
  }
}

Under the hood this is Gutenberg PR #73320 by Aki Hamano, merged June 24, 2026. It closes off the first checkbox on the “Typography: Add Text shadow support” tracking issue, which has been open since February 2023. Rich-text placeholders strip the shadow so empty state stays readable; real content keeps it in both editor and front end. Robertshaw calls the changes “additive” — existing themes do nothing, get nothing back, break in no way.

What is not shipping in 7.1 is worth naming. There is no block inspector control yet — no dropdown in the sidebar where an editor picks a shadow for one specific heading. There is no preset system in Global Styles UI either, no settings.typography.textShadowPresets, no var(--wp--preset--text-shadow--soft) custom properties. Those live in the still-open follow-up PR #79584, which adds block support on Paragraph and Heading, a preset settings schema, and a preset editing UI. That work is queued for a later release — Robertshaw is explicit about it.

So the 7.1 shape is deliberately narrow: theme authors define shadows in theme.json, everyone else waits for the UI layer. That is the right order.

Why it matters for WordPress and WooCommerce people

Three concrete reasons this lands differently than a usual “small typography addition” post.

First, the pattern that has been eating agency hours goes away. You know the one — client wants a hero heading with a soft drop shadow so white text stays readable over a photo of a product on a light background. Old flow: child theme, extra stylesheet, one .hero-title { text-shadow: ... } rule, a note in the handover doc, and a landmine for whoever redesigns the hero next year. New flow: two lines under styles.elements.h1.typography in theme.json, versioned with the theme, discoverable via wp theme.json tooling, gone from the “random CSS” pile.

Second, this is the same maturity signal the block editor keeps giving on other properties. Border radius, box shadow, letter spacing, text decoration — each one made the same walk from custom-CSS-only to theme.json property to preset system to block inspector control. Text shadow is now on step two. If you have watched box shadow go through the same journey, you already know how to plan the rest.

Third, WooCommerce framing. Store themes lean hard on hero photography and product cards. Text on top of imagery is where contrast fails and where designers reach for a shadow. Being able to bake a shadow into the H1 element or the button element via theme.json — not into a shortcode, not into a page builder module — makes the eventual migration between store themes cheaper, because the design token travels with the file.

What I would do (or not do) about it

A four-part plan for this week and next, if you build or maintain block themes.

• Audit your current text-shadow rules. Grep every custom stylesheet, child theme, and additional CSS for the property. Every rule found is a candidate to move into theme.json after August 19. Not on the same day — collect the list now, migrate on a scheduled window.
• Test on Beta 3, not on production. The Beta 3 build already carries this surface. Spin up a Playground blueprint or a staging clone, drop textShadow into a theme’s theme.json, verify the shadow renders in both editor and front end. Run the exact CSS values you already have in production so the diff is zero.
• Do not build a preset library yet. It is tempting to invent soft, glow, retro slugs today and register them via a plugin. Do not. The preset schema in PR #79584 is not merged. Anything you build now will need renaming when that surface lands. Wait one release cycle.
• Do not stack this on the WooCommerce 11.0 window. WC 11.0 lands July 28. WP 7.1 lands August 19. Two upgrade windows, two triage queues, three weeks apart. Do the WC 11.0 pass on WordPress 7.0.2 stable first, then plan the 7.1 pass separately. Sequential change windows save weekends.

One thing I would not do: reach for a plugin that adds a text-shadow inspector control today. The block-level UI is coming from core in the next release cycle. Any third-party control you adopt now becomes technical debt the moment core ships its own — and core ships better UX than most inspector plugins because it has to survive every theme in existence, not one.

The point of this feature is not the shadow. The point is one less snippet in the “random CSS” folder and one more design decision that lives inside the theme where it belongs.