tailwindlabs/tailwindcssv4.3.3

Tailwind CSS 4.3.3 improves watcher and plugin reliability

Tailwind CSS 4.3.3 fixes watcher polling, selector parsing, plugin theme resolution, nested CSS processing, and cross-platform font behavior. Teams using the CLI, PostCSS, Vite, or the upgrade tool should review these fixes.

Published
Coverage
Frontend
Desk
OpenStack Daily Editorial
A migration review with annotated release notes and architecture diagrams
A release report is a starting point. Project-specific tests remain the final compatibility check.

Release overview

tailwindlabs/tailwindcss published v4.3.3 on 2026-07-16. This page was generated deterministically from the public GitHub release and does not use an LLM.

View the official GitHub release

The report preserves upstream wording wherever possible. The breaking-change badge is based on explicit keywords, not semantic interpretation.

Official release notes

Fixed
  • Support --watch --poll[=ms] in @tailwindcss/cli when filesystem events are unreliable or unavailable (#20297)
  • Canonicalization: match arbitrary hex colors against theme colors case-insensitively (e.g. bg-[#fff] and bg-[#FFF]bg-white) (#20298)
  • Prevent Preflight from overriding Firefox's native iframe:focus-visible outline styles (#20292)
  • Ensure theme('colors.foo') in JS plugins resolves correctly when both --color-foo and --color-foo-bar exist (#20299)
  • Ensure fractional opacity modifiers work with named shadow sizes like shadow-sm/12.5, text-shadow-sm/12.5, drop-shadow-sm/12.5, and inset-shadow-sm/12.5 (#20302)
  • Parse selectors like [data-foo]div as two selectors instead of one (#20303)
  • Ensure @tailwindcss/postcss rebuilds when a preprocessor like Sass changes the input CSS without changing the input file on disk (#20310)
  • Ensure CSS nesting is handled even when Lightning CSS isn't run, such as in @tailwindcss/browser and Tailwind Play (#20124)
  • Prevent achromatic theme colors from shifting hue when mixed in polar color spaces like oklch (#20314)
  • Ensure --spacing(0) is optimized to 0px instead of 0 so it remains a <length> when used in calc(…) (#20319)
  • Load @parcel/watcher only when needed in @tailwindcss/cli --watch mode, so one-off builds and --watch --poll work when @parcel/watcher can't be loaded (#20325)
  • Use explicit platform fonts instead of system-ui and ui-sans-serif so CJK text respects the page's lang attribute on Windows (#20318)
  • Prevent @tailwindcss/upgrade from rewriting ignored files when run from a subdirectory (#20329)
  • Ensure earlier @source rules pointing to nested files are scanned when later @source rules point to files in parent folders (#20335)
  • Prevent @tailwindcss/vite from triggering full page reloads when scanned files are processed by Vite but haven't been loaded as modules yet (#20336)

Breaking changes and migration

The upstream notes do not contain an explicit breaking-change signal. This automated check is conservative, so verify deprecations and changed defaults in the official notes before upgrading.

Before the upgrade

1. Pin the currently deployed version.
2. Run the existing test and build suites.
3. Record warnings, bundle output, and runtime behavior.

After the upgrade

1. Install the exact release tag in a dedicated branch.
2. Run the same tests and production build.
3. Compare warnings, output, and critical user flows.

Verification checklist

  • Read the complete upstream release notes and linked migration documents.
  • Search the codebase for deprecated APIs and configuration keys named upstream.
  • Upgrade in an isolated branch with a lockfile diff that can be reviewed.
  • Run unit, integration, end-to-end, and production-build checks that apply to the project.
  • Keep a rollback commit or previously deployed artifact available.

Frequently asked questions

Is this report generated by artificial intelligence?

No. The sync script fetches structured release data from GitHub and writes a fixed Markdown template. It does not call an LLM or send release content to an AI provider.

How is the breaking-change badge determined?

The script looks for explicit phrases such as "breaking change," "backward incompatible," "migration required," and "removed." This is a useful signal, but it cannot replace a developer reading the upstream notes.

Does the site modify the official release notes?

It only demotes heading levels so the upstream notes fit inside the article hierarchy. The original release link is always included for verification.

Can this report decide whether an upgrade is safe?

No. It provides discovery, provenance, and a consistent checklist. Compatibility decisions still require project-specific tests and engineering review.