HTML Guides for textarea
Learn how to identify and fix common HTML validation errors flagged by the W3C Validator — so your pages are standards-compliant and render correctly across every browser. Also check our Accessibility Guides.
The type attribute is specific to the <input> element, where it determines the kind of input control rendered — such as text, checkbox, email, or number. The <textarea> element serves a single, distinct purpose: providing a multi-line plain-text editing area. Because it doesn’t have multiple modes of operation, the HTML specification does not define a type attribute for it.
This error commonly occurs when developers confuse <textarea> with <input>, or when refactoring a single-line <input type="text"> into a multi-line <textarea> without removing the now-invalid type attribute. It can also appear when using templating systems or frameworks that apply attributes generically across different form elements.
While browsers will typically ignore the unrecognized type attribute on a <textarea>, keeping it in your markup causes W3C validation errors and can lead to confusion for other developers reading the code. Invalid attributes may also interfere with CSS attribute selectors (e.g., textarea[type="text"] is a selector targeting invalid markup), accessibility tools, or automated testing systems that rely on well-formed HTML.
To fix this issue, remove the type attribute from the <textarea> element. If you need to differentiate between multiple textareas, use id, name, or class attributes instead. If you actually need a single-line text input, use <input type="text"> rather than <textarea>.
Examples
Incorrect: type attribute on <textarea>
<label for="comment">Your comment:</label>
<textarea type="text" id="comment" name="comment" rows="4" cols="50"></textarea>The type="text" attribute is not valid on <textarea> and will trigger a validation error.
Correct: <textarea> without type
<label for="comment">Your comment:</label>
<textarea id="comment" name="comment" rows="4" cols="50"></textarea>Simply removing the type attribute resolves the issue. The <textarea> element inherently provides a multi-line text input, so no type is needed.
Correct: Using <input> when a single-line field is intended
If you intended a single-line text field, use <input> instead:
<label for="username">Username:</label>
<input type="text" id="username" name="username">The type attribute is valid and expected on <input> elements, where it controls the type of input control rendered.
Remove the empty maxlength and provide a valid non‑negative integer, or omit maxlength entirely.
The maxlength attribute limits the number of characters a user can enter. It must be a valid non-negative integer (0, 1, 2, …). An empty string, whitespace, or non-numeric value fails validation. When maxlength is omitted, the length is unlimited. When set to 0, no characters can be entered. The value applies to the textarea element itself, not its content.
Common fixes:
- Set maxlength to a concrete number like 200.
- If you don’t need a limit, remove the attribute.
- Ensure templating doesn’t output an empty attribute (e.g., maxlength="").
HTML Examples
Invalid example (reproduces the validator error)
<!DOCTYPE html>
<html lang="en">
<head>
<title>Invalid maxlength</title>
</head>
<body>
<form>
<label for="msg">Message</label>
<textarea id="msg" name="message" maxlength=""></textarea>
</form>
</body>
</html>Fixed example (valid integer or omit attribute)
<!DOCTYPE html>
<html lang="en">
<head>
<title>Valid maxlength</title>
</head>
<body>
<form>
<label for="msg">Message (max 200 chars)</label>
<textarea id="msg" name="message" maxlength="200"></textarea>
</form>
</body>
</html>The <textarea> element represents a multi-line plain-text editing control, commonly used for comments, feedback forms, and other free-form text input. The rows attribute specifies the number of visible text lines the textarea should display. According to the HTML specification, when the rows attribute is present, its value must be a valid positive integer — meaning a string of one or more digits representing a number greater than zero (e.g., 1, 5, 20). An empty string ("") does not meet this requirement.
This issue typically occurs when a template engine, CMS, or JavaScript framework dynamically sets the rows attribute but outputs an empty value instead of a number, or when a developer adds the attribute as a placeholder intending to fill it in later.
Why this matters
- Standards compliance: The HTML specification explicitly requires rows to be a positive integer when present. An empty string violates this rule.
- Unpredictable rendering: Browsers fall back to a default value (typically 2) when they encounter an invalid rows value, but this behavior isn’t guaranteed to be consistent across all browsers and versions.
- Maintainability: Invalid attributes can mask bugs in dynamic code that was supposed to provide a real value.
How to fix it
You have two options:
- Set a valid positive integer: Replace the empty string with a number like 4, 5, or whatever suits your design.
- Remove the attribute: If you don’t need to control the number of visible rows (or prefer to handle sizing with CSS), simply omit the rows attribute. The browser will use its default.
If the value is generated dynamically, ensure your code has a fallback so it never outputs an empty string. You can also control the textarea’s height using CSS (height or min-height) instead of relying on the rows attribute.
Examples
❌ Invalid: empty string for rows
<textarea name="comments" rows="" cols="25">
</textarea>This triggers the error because "" is not a valid positive integer.
✅ Fixed: providing a valid positive integer
<textarea name="comments" rows="5" cols="25">
</textarea>Setting rows="5" tells the browser to display five visible lines of text.
✅ Fixed: removing the attribute entirely
<textarea name="comments" cols="25">
</textarea>When rows is omitted, the browser uses its default (typically 2 rows). This is perfectly valid.
✅ Alternative: using CSS for sizing
<textarea name="comments" style="height: 10em; width: 25ch;">
</textarea>If you need precise control over the textarea’s dimensions, CSS properties like height, min-height, and width give you more flexibility than the rows and cols attributes. In this case, you can safely leave both attributes off.
The HTML specification defines specific rules about which autocomplete values can be used on which form elements. The street-address token is categorized as a “multiline” autofill field because street addresses often span multiple lines (e.g., “123 Main St\nApt 4B”). Since <input> elements only accept single-line text, the spec prohibits using street-address with them. The <textarea> element, on the other hand, naturally supports multiline content, making it the appropriate host for this token.
This matters for several reasons. First, browsers use autocomplete values to offer autofill suggestions. When the element type doesn’t match the expected data format, browsers may not autofill correctly or may ignore the hint entirely. Second, standards compliance ensures consistent behavior across different browsers and assistive technologies. Third, using the correct pairing improves the user experience — users expect their full street address to appear in a field that can actually display it properly.
You have two approaches to fix this:
-
Use a <textarea> — If you want the full street address in a single field, switch from <input> to <textarea>. This is the most semantically correct choice when you expect multiline address data.
-
Use line-specific tokens on <input> elements — If your form design uses separate single-line fields for each part of the address, use address-line1, address-line2, and address-line3 instead. These tokens are explicitly allowed on <input> elements.
Examples
❌ Invalid: street-address on an <input>
<label for="address">Street Address</label>
<input type="text" id="address" name="address" autocomplete="street-address">This triggers the validation error because street-address requires a multiline control.
✅ Fix: Use a <textarea> with street-address
<label for="address">Street Address</label>
<textarea id="address" name="address" autocomplete="street-address"></textarea>The <textarea> supports multiline text, so street-address is valid here.
✅ Fix: Use line-specific tokens on <input> elements
<label for="address1">Address Line 1</label>
<input type="text" id="address1" name="address1" autocomplete="address-line1">
<label for="address2">Address Line 2</label>
<input type="text" id="address2" name="address2" autocomplete="address-line2">The address-line1, address-line2, and address-line3 tokens are single-line autofill fields and are perfectly valid on <input> elements. This approach is common in forms that break the address into separate fields for apartment numbers, building names, or other details.
Summary of allowed pairings
| Token | <input> | <textarea> |
|---|---|---|
| street-address | ❌ Not allowed | ✅ Allowed |
| address-line1 | ✅ Allowed | ✅ Allowed |
| address-line2 | ✅ Allowed | ✅ Allowed |
| address-line3 | ✅ Allowed | ✅ Allowed |
Choose the approach that best fits your form layout. If you prefer a single address field, use <textarea> with street-address. If you prefer structured, separate fields, use <input> elements with the appropriate address-line tokens.
Invalid value “virtual” was used for the wrap attribute on a textarea.
The wrap attribute controls how the browser wraps text when submitting a form. It accepts only two keyword values:
- soft (default): Lines are not hard-wrapped on submission; the server receives unwrapped lines.
- hard: The browser inserts CRLFs at wrap boundaries on submission; you must also set cols for hard to be valid.
virtual was a non-standard value used by some legacy browsers and is not allowed by the HTML Standard or the W3C validator. Remove wrap entirely to get soft wrapping, or set it to soft/hard as needed. If you choose hard, include a sensible cols value. You can also control visual wrapping with CSS like white-space if needed.
HTML Examples
Example: Reproduces the validator error
<!doctype html>
<html lang="en">
<head>
<title>Textarea Wrap Error</title>
</head>
<body>
<form>
<label for="msg">Message</label>
<textarea id="msg" name="msg" wrap="virtual"></textarea>
</form>
</body>
</html>Example: Valid fixes
<!doctype html>
<html lang="en">
<head>
<title>Textarea Wrap Fix</title>
</head>
<body>
<form>
<label for="msg-soft">Message (soft)</label>
<textarea id="msg-soft" name="msg" wrap="soft"></textarea>
<label for="msg-hard">Message (hard)</label>
<textarea id="msg-hard" name="msg" wrap="hard" cols="40" rows="5"></textarea>
</form>
</body>
</html>The <a> element is classified as interactive content, and the HTML spec explicitly states that interactive content must not be nested inside other interactive content. A <textarea> is a form control that accepts user input—clicking, focusing, typing, and selecting text within it. When it’s wrapped in a link, the browser faces a conflict: should a click focus the textarea or follow the link? Different browsers may resolve this differently, leading to inconsistent behavior.
Beyond browser inconsistency, this nesting creates serious accessibility problems. Screen readers and other assistive technologies rely on a clear, predictable document structure. When a form control is buried inside a link, the roles and interaction models overlap, making it confusing or even impossible for users relying on keyboard navigation or screen readers to interact with either element properly.
The fix depends on what you’re trying to achieve. If the <textarea> and the link are logically separate, simply move them to be siblings rather than nesting one inside the other. If you need them to appear visually grouped, use a wrapper <div> or another non-interactive container element instead.
Examples
❌ Invalid: <textarea> inside an <a> element
<a href="/comments">
<textarea name="comment" rows="4" cols="40"></textarea>
</a>This triggers the validation error because the <textarea> is a descendant of the <a> element.
✅ Valid: <textarea> and <a> as siblings
<div>
<textarea name="comment" rows="4" cols="40"></textarea>
<a href="/comments">View all comments</a>
</div>Here, both elements live side by side inside a neutral <div>, avoiding any nesting conflict.
✅ Valid: <textarea> inside a <form> with a separate link
<form action="/submit-comment" method="post">
<label for="comment">Your comment:</label>
<textarea id="comment" name="comment" rows="4" cols="40"></textarea>
<button type="submit">Submit</button>
</form>
<a href="/comments">View all comments</a>This is the most semantically correct approach when the textarea is part of a form—keep the form controls in a <form> and place any navigation links outside of it.
Other interactive elements to watch for
The same rule applies to other interactive content inside <a> elements. You also cannot nest <button>, <input>, <select>, <details>, or another <a> inside a link. If the validator reports a similar error for any of these elements, the fix follows the same principle: move the interactive element out of the anchor.
Ready to validate your sites?
Start your free trial today.