Browser Build and Play CDN Runtime
Purpose and Scope
This page explains Tailwind CSS’s browser-facing runtime story: the Play CDN path for trying Tailwind directly in a page, and the build-tool path used by real applications that still run in the browser after compilation. Tailwind’s documented production model is to scan source files, generate matching styles, and write static CSS, so the Play CDN should be understood as a convenience runtime rather than the normal deployment architecture. The goal for readers is to choose the right browser workflow before they invest in project structure, local packages, or production build configuration.
The repository source requested for this page shows the application side of that choice. The Vite playground entry imports React and ReactDOM, imports the local application component, imports the root stylesheet, and mounts the component tree into a DOM element named app. That small file is a useful reference because it shows Tailwind participating through ordinary source files and the bundler module graph instead of through a script tag in the document. In other words, both workflows end in a browser, but they put Tailwind in very different places in the system. Sources: playgrounds/vite/src/main.tsx
The official Play CDN documentation describes a deliberately lightweight path: add the browser package script to the head of an HTML file, then write utility classes directly in the markup. It also states that this path is designed for development purposes only and is not intended for production. That distinction matters for teams because the runtime that makes a one-file demo convenient is not the same thing as the zero-runtime CSS output expected from a production Tailwind setup. Treat the CDN as a learning and prototyping environment, then graduate to Vite, PostCSS, the CLI, or a framework guide when the experiment becomes an application.
Relevant Source Files
playgrounds/vite/src/main.tsx— Demonstrates the build-tool browser application path used by the Vite playground: React and ReactDOM are imported as modules, the local app component is rendered into the page, and Tailwind-bearing CSS enters the application through a root CSS import.
Runtime Models
The Play CDN model starts with a plain HTML document. A developer adds the browser package script, writes elements with Tailwind utilities such as text sizing, font weight, decoration, display, spacing, or interaction classes, and refreshes the page to see results. Because there is no package install or build command in this flow, it is especially useful for tutorials, reduced reproductions, design sketches, and quick verification of utility names. It reduces the setup problem to a single document, which is exactly why it is valuable for learning Tailwind’s utility-first vocabulary.
That convenience comes with an explicit boundary. The CDN workflow performs Tailwind work in the browser, while the normal Tailwind architecture produces CSS before deployment. For production applications, a build step can scan the project’s templates and components, generate only the styles the project needs, integrate with the rest of the toolchain, and ship static CSS to users. The Vite playground source illustrates this production-oriented shape: the browser receives an application assembled from modules, and the stylesheet is imported from source rather than authored as an inline browser-only experiment. Sources: playgrounds/vite/src/main.tsx
The build-tool model is also easier to reason about as an application grows. The entry module can be kept small, as the playground demonstrates, while component files hold UI structure and a shared stylesheet holds Tailwind directives, custom CSS, or theme definitions. The root module does not need to know every utility class in the app; it only establishes the JavaScript and CSS graph. That separation gives teams a clean migration path from a demo to a project: keep the same class-based styling approach, but move Tailwind processing out of the document and into the project pipeline.
System-to-Code Mapping
The concrete source mapping is intentionally compact. The first imports bring in React and the ReactDOM client renderer, the next import brings in the local App component, and the stylesheet import pulls the app’s CSS into the Vite module graph. The render call then creates a root from the page element and renders the App inside React Strict Mode. Tailwind is not visible as a function call in this file because, in a Vite-style setup, Tailwind behavior is expressed through CSS and integration tooling rather than through imperative application code. Sources: playgrounds/vite/src/main.tsx
That mapping is the main contrast with the Play CDN. In the CDN model, the HTML document is the integration surface: the script tag loads the browser runtime, the body contains class names, and optional Tailwind-aware style blocks can define custom CSS. In the Vite model, the integration surface is the source graph: the root TypeScript file imports CSS, Vite handles module loading during development, and the production build emits browser assets. The same utility classes can appear in the resulting UI, but the lifecycle is different from authoring to runtime.
This distinction helps avoid a common misunderstanding. The browser package is not a general recommendation to ship Tailwind as a client-side framework. It is a browser-hosted way to try Tailwind without a local build step. The Vite playground, by contrast, demonstrates a browser application that still relies on a build tool for dependency loading and CSS processing. When documenting or debugging a Tailwind issue, note which side of this boundary the reproduction uses, because a CDN-only page and a Vite application have different places to look for configuration, source scanning, stylesheet imports, and production output.
Execution Flow
For a Play CDN experiment, start with one HTML file. Add the browser package script to the document head, place the interface markup in the body, and add utility classes directly to elements. If the page needs customization, the official documentation shows a style element with the Tailwind-specific text type and an at-theme block that defines a custom color variable. The page can then use a corresponding utility in the markup. This is the shortest path when the reader wants to test a design idea without installing dependencies or creating a project.
For a Vite-style application, start from the project’s HTML shell and root module. The shell provides the mount element, and the TypeScript entry point locates that element before rendering the application. The requested playground source uses a non-null DOM lookup for the app element, creates a React root, wraps the component tree in Strict Mode, and renders the local App component. Its stylesheet import is the key Tailwind handoff: instead of asking the browser package to interpret Tailwind from the document, the app asks the build pipeline to load and transform CSS as part of the source graph. Sources: playgrounds/vite/src/main.tsx
The operational difference is important during iteration. In a CDN page, changing markup or an inline Tailwind style block is enough to test the idea, but the page remains a self-contained runtime experiment. In a Vite app, changes flow through the development server, module graph, and CSS pipeline, so the setup supports multiple files, reusable components, dependency management, and a production build command. The Vite playground entry is intentionally minimal because the complexity belongs elsewhere in the toolchain, not in the browser mounting code. Sources: playgrounds/vite/src/main.tsx
API and Configuration Reference
| Name or surface | Role in the browser workflow | When to use it |
|---|---|---|
@tailwindcss/browser@4 | Browser package used by the official Play CDN installation snippet | One-file experiments, learning, demos, and reduced reproductions |
type="text/tailwindcss" | Inline style block type used by the Play CDN workflow for Tailwind CSS features | Custom theme variables or Tailwind CSS features inside a CDN page |
./index.css | Root stylesheet imported by the Vite playground entry module | Build-tool applications where CSS participates in the source graph |
ReactDOM.createRoot(...).render(...) | Browser mounting step in the Vite playground | React applications served or built through Vite |
Use the reference table as a routing guide, not as a list of interchangeable APIs. The browser package script belongs in an HTML document that is intentionally avoiding a local build step. The stylesheet import belongs in an application entry module where the build tool understands CSS imports. The ReactDOM render call is not Tailwind-specific, but it shows the surrounding application runtime that Tailwind must fit into when a project uses React and Vite. The requested source makes that relationship clear by keeping styling integration as a CSS import rather than as runtime Tailwind JavaScript. Sources: playgrounds/vite/src/main.tsx
A useful rule is to locate the Tailwind authoring surface before choosing documentation. If the authoring surface is a single HTML file, read the Play CDN guidance and keep expectations limited to development usage. If the authoring surface is a project stylesheet imported from a module entry, read the Vite or PostCSS setup pages and the package API pages for build integration details. If the authoring surface is a framework-specific app directory, start with the framework guide and then follow the underlying integration page that the framework uses.
Edge Cases and Migration Guidance
The most common edge case is a prototype that outgrows the Play CDN. That does not mean the prototype was wrong; it means its constraints changed. Once the page needs multiple components, shared CSS, local packages, source control conventions, tests, or a deployable production artifact, move the Tailwind processing into a build tool. The migration is conceptual rather than stylistic: keep writing utility classes in markup and components, but stop depending on the document-level browser runtime as the place where Tailwind work happens.
Another edge case is debugging missing styles. In a CDN document, check that the browser package script is present before the markup and that custom Tailwind CSS uses the documented style type. In a Vite application, the first sanity check is different: ensure the root module imports the stylesheet that contains the Tailwind entry CSS. The playground demonstrates that import directly, so a Vite reproduction that omits its equivalent may render React successfully while failing to include Tailwind-generated styles. Sources: playgrounds/vite/src/main.tsx
Choosing the Right Path
Choose the Play CDN when setup speed is more important than production architecture. It is ideal for learning the display, spacing, typography, state, responsive, and theme concepts from the documentation because the feedback loop is just editing a document. Choose a build-tool workflow when the project needs structure, repeatability, production output, or integration with a framework. The Vite playground source shows the shape of that second path: a module entry loads the app and imports CSS, leaving Tailwind to the stylesheet and build integration rather than the browser document. Sources: playgrounds/vite/src/main.tsx
Next, read the Play CDN page for the one-file browser workflow, the Using Vite and Vite Plugin pages for the build-tool route, and the tailwindcss Package API page when you need to understand compiler entry points used by integrations. If you are choosing an installation path for a new project, start with Installation, then follow the route that matches your authoring surface. If you are maintaining an existing project, first identify whether Tailwind is being run in the browser, through Vite, through PostCSS, through the CLI, or through a framework wrapper.