CSS field-sizing: Content-Sized Forms Without JavaScript

TL;DR: CSS field-sizing: content lets native form controls size themselves from their actual value instead of a browser-default width. It removes a surprising amount of measurement JavaScript for compact search boxes, token editors, growing textareas, and value-aware selects—provided you set deliberate minimum and maximum dimensions and retain a robust fallback. The property is defined in CSS Basic User Interface Level 4, and it is worth treating as progressive enhancement rather than as a reason to remove every layout constraint from a form.

Table of contents

• What problem does field-sizing solve?
• Which controls change size?
• How do you use field-sizing: content safely?
• Where does it replace JavaScript?
• What are the layout and accessibility traps?
• How should a production team ship it?
• FAQ

What problem does field-sizing solve?

Native form fields have historically had an awkward relationship with intrinsic sizing. A text input usually starts at a UA-defined width, a textarea gets a fixed number of rows and columns, and a select often reserves space according to browser heuristics. That is sensible for ordinary forms, but it creates friction in dense interfaces: command bars, filter builders, spreadsheet-like controls, title fields, and inline search.

The usual workaround is JavaScript that mirrors a value into a hidden span, reads scrollWidth, or measures a textarea’s scrollHeight on every input. It works, but it also adds event wiring, font-loading edge cases, hydration concerns, and a small but recurring performance cost. field-sizing: content gives the browser a declarative answer: make this form control’s preferred size follow its contents.

.compact-search {
  field-sizing: content;
  min-inline-size: 14ch;
  max-inline-size: min(32rem, 100%);
}

In this example, a blank search box is still discoverable because the minimum is intentional. As the query grows, the control can grow until it reaches the available cap. That is the key pattern: content-based sizing is useful only when paired with product-level limits.

This continues a broader shift toward letting CSS own presentation logic that used to require listeners. For example, CSS sibling functions reduce state-driven UI glue, while CSS scroll-state queries make some scroll-derived visual state declarative. field-sizing is smaller in scope, but it follows the same maintenance-friendly direction.

Which controls change size with field-sizing: content?

The normative definition lives in the CSS UI Level 4 field-sizing section. The property has two keyword values: fixed, the initial behaviour, and content, which changes the preferred size calculation of certain form controls.

In practice, content applies to text-entry input types such as text, email, url, tel, search, number, and password; to textarea; to file inputs; and to select controls. The MDN property reference usefully documents the element-specific consequences.

That last point matters: it is not a universal width: fit-content switch.

• Text inputs can shrink to their cursor or placeholder and then expand as a person types.
• Textareas can grow inline first; when an inline constraint is reached, they grow in the block direction until that is constrained too, then scroll.
• Single-select controls can change width with the currently displayed option.
• Multiple selects and list boxes may grow to expose their options rather than preserving the familiar scrolling box.
• File inputs can adapt to the selected filename, but browser rendering still has native-control quirks worth testing.

The interactions with HTML attributes are easy to miss. On content-sized text inputs, size does not determine the preferred width. On a content-sized textarea, rows and cols no longer establish the preferred size. Those attributes remain meaningful fallback defaults, which makes them worth retaining. Their HTML semantics are specified in the WHATWG HTML input and textarea sections.

How do you use field-sizing: content safely?

Start with a bounded component, not a global reset. Applying it to every input can produce cursor-width fields, jumping rows, and select menus that destabilise a toolbar. A component class makes the decision visible in code review.

.title-editor {
  field-sizing: content;
  box-sizing: border-box;
  min-inline-size: 18ch;
  max-inline-size: 100%;
}

.note-editor {
  field-sizing: content;
  box-sizing: border-box;
  inline-size: 100%;
  min-block-size: 6lh;
  max-block-size: 18lh;
  max-inline-size: 72ch;
  resize: vertical;
}

The first component is an inline title editor. The second is a note field that begins at the width of its container, then gets taller as text wraps. lh is a useful unit here because the cap tracks the actual line height, though a rem-based value is perfectly acceptable if that better matches a design system.

Placeholder copy needs special care. Content-sized fields can use the placeholder when calculating their initial size, so a long sentence like “Search invoices by customer, date, amount, or status” can unexpectedly widen a control. Keep placeholders short, put extended guidance in a visible label or help text, and cap the inline size.

Avoid relying on growth as the only state signal. A field that grows when it has a value is not a substitute for a label, error message, clear button, or focus style. Native semantics are still the foundation: pair every control with a programmatic label and preserve :focus-visible styling.

Where does field-sizing replace JavaScript?

The best candidates are components whose JavaScript exists only to measure the rendered value.

Auto-growing comment boxes

The familiar textarea algorithm looks like this:

textarea.addEventListener('input', () => {
  textarea.style.height = 'auto';
  textarea.style.height = `${textarea.scrollHeight}px`;
});

It can be necessary as a fallback, but it reads layout after a write and needs careful handling during value restoration, font changes, and server rendering. With progressive enhancement, the baseline can stay simple:

textarea[data-grow] {
  min-block-size: 5lh;
  max-block-size: 16lh;
}

@supports (field-sizing: content) {
  textarea[data-grow] {
    field-sizing: content;
  }
}

If you already have a JavaScript autosize library, do not run both mechanisms together. Feature-detect in CSS and let the script attach only when support is absent. This is the same kind of gradual migration that makes browser features such as the View Transition API practical without sacrificing the base experience.

Inline filters and query builders

A token-like input next to selected filters can feel much less wasteful when it starts narrow and expands with the query. Set a usable minimum—roughly 8–14 ch depending on context—and a maximum so the input does not push critical buttons off a narrow screen.

For composed React components, let CSS own the size and keep React responsible for value, validation, and submission. This removes measurement effects and prevents layout work from becoming coupled to rendering. Teams adopting React Compiler in production should be especially wary of preserving effects that exist only because CSS once lacked a primitive.

Selects with volatile labels

When the displayed option is the meaningful thing—such as a country code, view mode, or short status—a content-sized select can be a good fit. It is a poor fit for a form grid where columns must align, or where option labels vary dramatically by language. In those cases, a fixed column is clearer than a control that moves the page as choices change.

What are the layout and accessibility traps?

The failure mode is not that field-sizing is complicated; it is that intrinsic sizing reveals constraints an interface did not define. Review these cases deliberately.

1. Empty controls. Without a minimum, an empty input may be little more than a caret. Set min-inline-size based on the task, not on whatever its placeholder happens to be.
2. Long unbroken content. URLs, IDs, generated filenames, and pasted tokens can expand a field aggressively. Use max-inline-size: 100% or a component-specific cap.
3. Mobile toolbars. A growing input inside a flex row can squeeze action buttons. Give the input a maximum and ensure sibling buttons have appropriate flex rules.
4. Multilingual UI. Localised placeholder and option strings are part of content sizing. Test the languages that are actually supported, including longer labels.
5. Keyboard and zoom. Test at 200% zoom and with keyboard navigation. Growth must not obscure the focused control, its label, validation feedback, or its submit button.
6. Layout shift. Growth in response to deliberate typing is normally expected. Growth caused by late value hydration or asynchronous data is more disruptive; reserve space or delay the visual transition in those flows.

Do not confuse an auto-growing textarea with an accessible writing experience. Character counts, error descriptions, and max-length feedback should remain explicit. Also, use the control’s natural scrolling behaviour after the cap is reached; trying to hide overflow can make editing impossible.

How should a production team ship it?

Treat support as a capability question, not as a browser-version guessing game. The MDN compatibility data is a helpful release-planning reference, but @supports is the runtime guard.

.composer {
  inline-size: 100%;
  min-block-size: 8lh;
  max-block-size: 20lh;
}

@supports (field-sizing: content) {
  .composer {
    field-sizing: content;
  }
}

This fallback is intentionally boring: a fixed-width, resizable textarea remains fully usable where the new property is unavailable. That is better than hiding the enhancement behind a component fork or making a server-rendered page depend on a client measurement pass.

Use a short rollout checklist:

• Identify fields whose measurement code is purely presentational.
• Add explicit minimum and maximum dimensions before enabling content sizing.
• Test empty, placeholder, long-value, validation, zoom, and localisation states.
• Verify each target browser with the real component—not just a standalone demo.
• Remove JavaScript measurement only after the fallback behaviour is confirmed.

Browser-native features earn their place when they delete complexity without making the product less predictable. field-sizing: content passes that test for targeted, bounded controls. It will not replace every form layout, but it can retire a class of fragile measuring code and make compact interfaces feel more responsive to the values people actually enter.

FAQ

Does field-sizing: content work on a textarea?

Yes. A content-sized textarea can grow to fit entered text. Give it sensible inline and block limits so it does not overwhelm the surrounding page; once constrained, the browser can use normal scrolling.

Does field-sizing replace width and height?

No. It changes the control’s preferred size calculation. Explicit width, height, min/max constraints, and the available container size still govern the final layout.

Should I remove rows, cols, or size attributes?

No. Keep them as semantic fallback defaults. With field-sizing: content, they may not determine the content-sized preferred dimensions, but they continue to provide useful baseline behaviour.

Can I use it on every form control?

Technically you can target several native controls, but globally applying it is rarely a good design choice. Use it where content-driven dimensions improve the task, and keep form grids, toolbars, and predictable columns intentionally constrained.