Generate a color-scheme meta tag and CSS property

Choose light when a page only supports a light interface, dark when it only supports a dark interface, or both when every relevant component has been designed for either appearance. The result is deterministic, normalized, and ready for a template, stylesheet, static site, component library, or build pipeline without remembering attribute names or value ordering.

Declare the schemes your interface genuinely supports

The color-scheme declaration is a promise about the page, not an automatic theme converter. Select light only when controls, backgrounds, text, borders, images, and focus states remain usable in a light presentation. Select dark only when those same parts have been deliberately prepared for a dark presentation. Choose both when the complete interface works in either scheme. The generator maps that last choice to the ordered value <code>light dark</code>, which advertises support for both while listing light first. Being accurate matters because browsers can use this information when rendering browser-controlled interface pieces such as form controls, scrollbars, and the canvas behind the document. A declaration that exaggerates support can therefore produce a page with mismatched native controls or unreadable flashes around content. Before copying the output, review states that are easy to miss: disabled inputs, autofill styling, validation messages, selected text, code blocks, embedded widgets, and icons with fixed fills. The best value is the narrowest truthful description of what the shipped page supports. This tool formats that description consistently; your design and testing establish whether the description is true.

Place the generated HTML and CSS in the right locations

Put the generated meta element inside the document's <code>&lt;head&gt;</code>, preferably early enough that the browser sees it before painting substantial interface chrome. The returned tag is complete, so it can be pasted into a static HTML document, a server-rendered layout, or the head configuration of a site generator. Put the CSS declaration in a rule that represents the scope you intend to describe. For a whole document, that will commonly be the <code>:root</code> rule; a component may instead apply the property to its own root when it establishes a contained scheme. The generator returns the bare declaration rather than wrapping it in a selector, which keeps it useful across plain CSS, preprocessors, CSS modules, and style objects that perform their own conversion. The HTML and CSS outputs use the same normalized value, avoiding a subtle disagreement between document metadata and stylesheet behavior. You may use both outputs together when your architecture benefits from an early document hint plus an explicit cascade value. You may also use only the output appropriate to your integration, but do so intentionally. After insertion, inspect the final rendered source and compiled CSS because frameworks, head managers, minifiers, or duplicate declarations can change which value actually reaches the browser.

Treat support declarations separately from theme selection

Supporting two schemes and choosing the active theme are related but different jobs. The value <code>light dark</code> says that either rendering is supported; it does not create color tokens, add a theme switcher, save a preference, or replace media queries. A robust implementation normally defines semantic variables for surfaces, text, borders, and accents, then changes those variables through the strategy the product has chosen. That strategy might follow the user's operating-system preference, honor an account setting, respond to a document attribute, or combine these approaches. Generate the declaration only after deciding which visual states are genuinely complete. Then test the page with light and dark system settings, forced browser overrides where available, keyboard navigation, zoom, and high-contrast or forced-color modes. Also check content that does not inherit your palette, including images, iframes, third-party forms, syntax highlighting, and native dialogs. In automation, store the selected input alongside the generated strings so reviewers can see the intention rather than reverse-engineering it from markup. If a product later drops one theme, regenerate both declarations from the new single choice instead of editing one output manually. Keeping the meta element and CSS property derived from one source prevents drift across templates, packages, and deployments.