CSS field-sizing: Auto-Resize Textareas and Inputs Without JavaScript

The auto-growing textarea has been a JavaScript problem for as long as textareas have existed: listen for input, read scrollHeight, reset the height to auto first so the measurement isn’t stale, set it again, repeat. Every framework has its own version of this hook. As of June 2026, it’s a CSS problem instead, and the CSS version is one line.

textarea {
  field-sizing: content;
}

That’s it. Type into the textarea and it grows. Delete text and it shrinks. No event listener, no measured scrollHeight, no layout thrash from reading and writing dimensions in the same frame.

Why this took until 2026 to be usable

Chrome shipped field-sizing: content behind a flag back in March 2024, but a Chrome-only feature isn’t a feature you can ship to production users on Safari or Firefox. Safari added support in version 26.2, released December 2025. Firefox was last, landing it in Firefox 152 in June 2026, and that’s the release that pushed field-sizing to Baseline Newly Available: the point where every major browser engine, Blink, WebKit, and Gecko, supports it in their current release. If you’ve been holding off on this property because “browser support” was a vague worry, that worry now has a specific, recent answer: it’s fine, as of a few weeks ago.

“Newly Available” is not the same as “safe for every user regardless of browser version,” though. Baseline Widely Available, the point where a feature has been out long enough that essentially all active browser installs support it, isn’t projected for this property until December 2028. If your traffic includes a meaningful share of users on older browser versions that never auto-updated, you still need a fallback path, which the last section covers.

The two values, and the one that matters

field-sizing takes two keyword values. fixed is the default and existing behavior: the control’s size comes from its width/height, rows/cols, or default UA sizing, same as every textarea has always worked. content is the new behavior described above.

/* Default behavior, unchanged from every textarea you've ever used */
textarea { field-sizing: fixed; }

/* New behavior: size follows content */
textarea { field-sizing: content; }

One easy mistake: field-sizing: content does nothing useful if you’ve also set a fixed width and height on the element, since those constraints still apply and override the content-based sizing. Drop explicit width and height (or at least height) for the property to actually take effect.

Capping growth with min-height and max-height

Used alone, field-sizing: content has no upper bound. A user pasting a few thousand words into a comment box will get a textarea that grows to match, which is rarely what you want in a real layout. The fix is standard CSS, using lh (line-height) units so the cap scales with the font size instead of being a hardcoded pixel guess:

textarea {
  field-sizing: content;
  min-height: 3lh;   /* never shorter than 3 lines */
  max-height: 12lh;  /* stop growing after 12 lines */
  overflow-y: auto;  /* scroll internally once max-height is hit */
}

This gives you a textarea that starts at a sensible size, grows naturally as someone writes a longer reply, and switches to an internal scrollbar instead of taking over the page once it hits your ceiling. The rows HTML attribute is still worth setting too, as a sizing hint that applies before your stylesheet has loaded and as a fallback for browsers that don’t support the property at all.

A complete, realistic example

Here’s a comment box pattern that combines the sizing behavior with the rest of what a real form control needs:

<textarea
  class="auto-textarea"
  rows="3"
  placeholder="Write a reply..."
></textarea>

.auto-textarea {
  field-sizing: content;
  min-height: 3lh;
  max-height: 15lh;
  overflow-y: auto;
  resize: none;         /* the manual drag-handle is redundant now */
  padding: 0.75rem 1rem;
  border-radius: 0.5rem;
  border: 1px solid #d1d5db;
  font: inherit;
  line-height: 1.5;
}

Turning off manual resize is a reasonable default once the field resizes itself, though it’s a judgment call. Some users still want to force a taller box for a reason the automatic sizing doesn’t anticipate, so leaving resize: vertical in place alongside field-sizing: content is also a defensible choice, and the two aren’t mutually exclusive.

Supporting browsers that don’t have it yet

For a product that still needs to support older browser versions, wrap the CSS in a feature query and keep the JavaScript version as the fallback:

@supports not (field-sizing: content) {
  /* your existing JS-driven auto-resize class or scrollHeight logic applies here */
}

This is the same progressive-enhancement pattern that’s applied to every other CSS feature with a JavaScript-equivalent predecessor: gap in flexbox before it had wide support, :has() before selector-based conditionals were reliable, and so on. Ship the CSS version for browsers that understand it, keep the old code path for the ones that don’t, and delete the JavaScript once your analytics show the older browsers aren’t worth the maintenance anymore.

If you’re auditing your design system for other places manual JavaScript sizing logic could come out now that the platform handles it natively, this is a good one to start with since it’s low-risk, easy to test, and the fallback path costs nothing to keep around during the transition. We cover the broader “what changed in browsers this year and is it safe to use” question in our state of CSS roundup, which is worth a read if field-sizing isn’t the only feature you’ve been putting off.