Textarea

Give someone a single-line box and they write a single line, whatever the actual answer needs. Give them five visible rows and they write closer to five. A textarea's height works as an instruction: it tells the person filling it in roughly how much you expect, before they have written a word.

Anatomy of a textarea

The parts below are mostly a text field's, plus one it does not have: a way to see more of a long answer, either by growing or by letting someone drag the corner themselves.

Here it is working. Type past the visible rows and watch what happens to the box rather than the scrollbar.

Variants

Autosizing. The box grows with the content and stops resizing manually being the person's job. Set a max-height so an extreme answer scrolls inside the box instead of pushing a submit button off the bottom of the screen.

Fixed height, manual resize. A set number of rows with the native resize handle left on. Reasonable for a field where most answers fit the box and the rare long one is fine to drag open.

With a character count. The count sits under the box, updates as they type, and only turns into a warning colour near the limit. It is a piece of information, not a running scoreboard.

States

The near-limit state is the one worth building deliberately. A counter that only appears at zero characters left has already failed. Show it early enough that reaching the limit is a decision, not a surprise.

How a textarea behaves

Tab moves focus out, not text in. Pressing Tab inside a plain textarea should move to the next field, the same as any other input. Trapping Tab to insert a tab character is correct in a code editor and wrong everywhere else, and it is a common accessibility bug in custom-built fields.

Enter always inserts a line break. A textarea has no concept of submitting a form on Enter, which is exactly why it is the wrong choice for a single-line answer that does expect that behaviour.

Growth needs a ceiling. An autosizing box with no max-height will happily grow to the length of a pasted document, taking the rest of the form with it. Cap the height and let the box scroll internally past that point.

Whitespace survives. Line breaks and multiple spaces are part of the value. Trim leading and trailing whitespace on submit, the same as a text field, but leave internal formatting alone.

Pasted content should never be silently cut. If a limit exists, accept the paste in full and show the field over its limit rather than truncating what someone just pasted in.

Textarea accessibility

Keyboard

The rest

• Contrast. The border or fill needs 3:1 against the page at rest (WCAG 1.4.11).
• 16px minimum text size. Same rule as a text field. Safari on iOS zooms the page in on focus if the font is smaller, and the zoom does not reset on blur.
• Label it the same way a text field is labelled. An explicit <label for> connection, never a placeholder standing in for one.
• The resize handle has no keyboard equivalent in most browsers. This does not fail WCAG, because the content stays fully readable through internal scrolling. It is worth knowing rather than assuming keyboard users can drag the corner the way a mouse user does.

What a textarea should say

Labels are nouns. "Cover letter" beats "Write your cover letter here".

Put format guidance in a hint, not a placeholder. "Include your order number if you have it" belongs under the label, where it survives the first keystroke.

Character counts read as a number, not a scold. "420 characters left" or "128 / 500", never "You have used 128 of your 500 characters".

Errors name the field and the fix. "Message must be under 500 characters, you are 40 over" beats "Too long".

Common textarea mistakes

The one that shows up constantly is a two-row box for an answer that was always going to run to a paragraph, so every response gets read through a porthole.

1. A fixed, tiny box for an answer with no natural length. Bug reports, cover letters and support messages do not fit in two rows. Size the box to a realistic answer, not the smallest space that technically fits the label.

2. Removing the resize handle from a fixed box with no autosize. That leaves someone stuck viewing four lines of a much longer answer with no way to see more of it.

3. A character counter from the very first keystroke. "0 / 500" on an empty field is pressure with no information in it yet.

4. Placeholder text standing in for the label. It disappears on the first character typed, on the field most likely to hold something someone needs to check back on.

5. Autosizing with no maximum height. A pasted paragraph or a long paste-in of code takes the submit button with it as the box grows without limit.

6. Truncating a paste that exceeds the limit. Silently cutting off the end of what someone just pasted loses content they never saw disappear.

How to build a textarea

<div class="field">
  <label for="message">Message</label>
  <textarea
    id="message"
    name="message"
    rows="5"
    maxlength="500"
    aria-describedby="message-count"
    style="field-sizing: content; max-height: 320px;"
  ></textarea>
  <p id="message-count">0 / 500</p>
</div>

const textarea = document.getElementById("message");
const counter = document.getElementById("message-count");
textarea.addEventListener("input", () => {
  counter.textContent = `${textarea.value.length} / 500`;
});

field-sizing: content autosizes the box with no JavaScript at all. It shipped in Chromium-based browsers first and has been landing across the rest since, so pair it with a max-height and treat a manual scrollHeight resize as the fallback where it is not yet supported.

Edge cases

A single word longer than the box. A pasted URL with no spaces needs overflow-wrap: break-word, or it pushes the field wider than its container.

Zoom to 200 percent. The label, box and hint all need to stay visible and inside the viewport (WCAG 1.4.4).

Right to left. The text and the resize handle both mirror. Use logical properties so the handle ends up in the correct corner without a second stylesheet.

Hidden then shown. An autosizing textarea measured while display: none reports a height of zero. Measure again after it becomes visible, or the box opens collapsed.

A slow save. If the content saves as someone types (a draft), show that state near the field rather than on it, so it does not compete with the text being written.

Textareas in real products

GitHub autosizes its comment and pull request description boxes as you type, keeps the native resize handle active on top of that, and caps growth with an internal scrollbar once a comment gets long.

X (formerly Twitter) shows nothing until you approach its 280-character limit, then a numeric countdown appears and turns red at zero, letting the last characters go slightly negative rather than blocking the keystroke outright.

Linear autosizes an issue's description field with a generous maximum height, switching to internal scrolling for anything longer rather than letting the field crowd the rest of the panel out of view.