Free · Fast · Privacy-first

Validate HTML Attributes Online

Attribute errors in HTML are a category of mistake that often goes unnoticed during development because browsers silently fall back to default behavior when they encounter an invalid attribute value, leaving the page rendering with subtle but real bugs.

⚡

Validates enumerated attribute values against the HTML spec

🔒

Checks boolean attribute syntax

✨

Flags invalid data-* attribute naming patterns

⚡

Validates ARIA attribute usage and values

Cost: Free forever
Sign-up: Not required
Processing: In your browser
Privacy: Files stay local

FreeNo signupWhite-label

Add this HTML Validator to your website

Drop the HTML Validator into any page — blog post, product docs, intranet, school portal — with a single line of HTML. Your visitors get the full tool, processed entirely in their browser. No backend, no uploads, no signup.

Files stay 100% in the visitor's browser
Responsive — adapts to any container width
Free forever, no API key needed

Embed code

<iframe
  src="https://www.fixtools.io/html/html-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

<iframe
  src="https://www.fixtools.io/html/html-validator?embed=1"
  width="100%"
  height="780"
  frameborder="0"
  style="border:0;border-radius:16px;max-width:900px;"
  title="HTML Validator by FixTools"
  loading="lazy"
  allow="clipboard-write"
></iframe>

Attribution-friendly: a small "Powered by FixTools" link appears in the embed footer.

HTML Attribute Types: Enumerated, Boolean, Data, and ARIA Attribute Rules

The HTML specification defines attributes in several categories, and each category has its own validity rules that the validator applies. Enumerated attributes have a fixed list of permitted values defined by the spec, and any value outside that list is treated as the missing-value default. The input element's type attribute is enumerated with twenty-two permitted values covering hidden, text, search, tel, url, email, password, date, month, week, time, datetime-local, number, range, color, checkbox, radio, file, submit, image, reset, and button; any other value causes the browser to treat the field as type="text" silently. The crossorigin attribute has three permitted values: anonymous, use-credentials, and the empty string. The autocomplete attribute has a list of permitted tokens that vary by input type. Validators check that enumerated attribute values are in the permitted set and flag any value not recognised by the spec, including common typos like "sumbit" for the submit input type or "emial" for email.

Boolean attributes in HTML5 have a specific syntax rule that catches many developers used to other markup languages off guard. The attribute name can appear without any value at all, with an empty string value, or with a value equal to the attribute name itself. For example, disabled, disabled="", and disabled="disabled" are all valid and equivalent forms that mean exactly the same thing to the browser. The incorrect form, which is sometimes seen in code migrated from XHTML or generated by template systems that do not understand HTML5 boolean syntax, is disabled="true" or disabled="false". The value "false" does not negate a boolean attribute in HTML5; it just sets the attribute to the string "false", which is still truthy in boolean attribute terms because the attribute is present at all. The correct way to remove a boolean attribute is to omit it entirely from the markup. Validators flag the "true" and "false" patterns as incorrect boolean attribute values.

Data attributes use the prefix data- followed by a custom name component that you choose. The HTML spec requires the custom part to contain no uppercase ASCII letters (A-Z), no colons, and at least one character after the data- prefix. A data attribute named data-userID violates the uppercase restriction because of the capital ID at the end; data- alone with no suffix is also invalid because the custom part is empty. Custom attribute names often appear valid to a casual reading but contain subtle spec violations that surface only under validation. ARIA attributes, by contrast, are defined by the WAI-ARIA specification, which lists every aria-* attribute name explicitly and specifies the elements and roles on which each attribute is permitted, required, or prohibited. Using aria-checked on a div without an appropriate role attribute, or using an undefined aria-* attribute name that does not exist in the spec, are both spec violations that validators report.

There is one further category worth mentioning, which is the use of custom attributes that do not follow the data-* convention. Adding attributes without the data- prefix, such as a hypothetical custom-attr="value" on a div element, is an HTML spec violation that validators flag as an unknown attribute error. Custom attributes should always use the data- prefix to declare their custom nature explicitly. Framework-specific attributes that appear in component templates, such as Vue's v-bind directives, Angular's property bindings, or React-style camelCase event handlers, should not appear in the rendered HTML output that reaches the browser because the framework processes them at build or render time and removes them. If you validate the rendered output and see these framework attributes still present, that is a sign that the framework rendering is not working correctly.

HTML Living Standard (WHATWG)WAI-ARIA Specification (W3C)

How to use this tool

💡

Paste your HTML and validate. Focus on attribute errors: invalid enumerated values, boolean attribute misuse, data attribute naming violations, and ARIA attribute errors. Each error includes the attribute name and element location.

How It Works

Step-by-step guide to validate html attributes online:

1
Paste HTML
Paste your HTML including all elements with attributes that you want to validate. The validator needs the full element context to apply attribute rules correctly because some attribute validity depends on the element type and other attributes that are present on the same element.
2
Validate
Click the validate button to run the full attribute rule check across all the elements in your document. The validator will examine every attribute on every element and report any that violate spec rules for enumerated values, boolean syntax, data attribute naming, ARIA usage, or general attribute presence.
3
Review attribute errors
Look for errors describing invalid attribute values that fall outside permitted enumerations, unknown attributes on specific elements that the spec does not recognise on those elements, and ARIA attribute violations including invalid role names and attribute-role mismatches.
4
Fix attribute values
Correct enumerated values to match the permitted list defined by the spec, fix boolean attribute syntax by removing "true" and "false" values that should not be present, and remove or correct invalid ARIA attributes that do not match the WAI-ARIA specification.
5
Revalidate
Confirm that all attribute errors have been resolved by running another validation pass after applying your fixes. The error count should drop to zero for attribute-related issues if the fixes were applied correctly to each flagged element.

Real-world examples

Common situations where this approach makes a real difference:

Catching misspelled input type values

A contact form has an input with type="sumbit" (misspelled) where the developer intended type="submit". Browsers silently treat the misspelled value as type="text", making the submit button appear and behave as a text input field that does nothing when clicked. HTML validation catches the invalid enumerated value immediately on the first validation pass, preventing what would have been a critical form usability bug from reaching production where users would discover it by being unable to submit the form at all.

Auditing a component library for ARIA attribute correctness

A shared component library uses ARIA attributes across many custom interactive elements like dropdowns, dialogs, and tabbed interfaces. Validation catches aria-selected being used on elements without an appropriate role attribute that supports the aria-selected state, an undefined aria-* attribute name introduced by a typo during a recent refactor, and several instances of aria-required on elements where the implicit required state from the underlying HTML form attribute already provides the same information.

Fixing boolean attribute patterns from an XHTML migration

HTML migrated from XHTML 1.0 contains many instances of disabled="true", readonly="true", and checked="true" because the XHTML strict doctype required attribute values for every attribute. HTML validation flags these as invalid boolean attribute values because HTML5 boolean attributes do not accept "true" or "false" string values. Replacing them with the bare attribute name form (just disabled, just readonly, just checked) brings the markup into HTML5 compliance and matches modern conventions.

Validating data attributes in a JavaScript-driven component

A component uses data-userId (with an uppercase I in the middle) as a data attribute meant to store the user identifier for JavaScript access. Validation flags the uppercase character as invalid in a data attribute name because the spec prohibits uppercase ASCII in the custom portion. Renaming the attribute to data-user-id fixes the error and ensures consistent programmatic access via the dataset API, which automatically converts hyphenated names to camelCase for JavaScript access.

Pro tips

Get better results with these expert suggestions:

disabled="false" does not disable anything

Boolean attributes in HTML5 are presence-based rather than value-based. The value of a boolean attribute is irrelevant once it is present on an element; if the attribute name appears at all, it is considered active. Writing disabled="false" means the element IS disabled, not that it is enabled, because the disabled attribute is present regardless of its value. Remove the attribute entirely from the markup to remove the disabled state. Validators flag "true" and "false" as invalid boolean attribute values precisely because this is such a common source of confusion.

data-* attribute names must be lowercase

The HTML spec requires that the custom part of a data-* attribute name contain no uppercase ASCII letters from A through Z. data-itemId is invalid because of the uppercase I; data-item-id or data-itemid are both valid alternatives. JavaScript's dataset API converts hyphenated names to camelCase automatically when you read them: data-item-id becomes dataset.itemId in JavaScript. Use hyphenated lowercase names in your HTML and let the dataset API handle the camelCase conversion on the JavaScript side.

Custom attributes that are not data-* are invalid

Adding non-standard attributes without the data- prefix, such as custom-attr="value" or my-thing="value" on an HTML element, is an HTML spec violation that validators flag as an unknown attribute error. Custom attributes should always use the data- prefix to declare their custom status explicitly. Framework-specific attributes like Vue's v-bind directives or Angular's property bindings appear in template source but should not appear in the final rendered HTML output that reaches the browser because the framework strips them at build or render time.

Check the permitted ARIA attributes for each role

The WAI-ARIA specification defines exactly which aria-* attributes are permitted, required, or prohibited for each ARIA role. Using aria-checked on an element with role="link" is invalid because the link role does not support the aria-checked state in the ARIA spec. The complete attribute-to-role mapping is documented in the WAI-ARIA specification and is also surfaced through validator warnings when mismatches are detected. Consult the spec or validator output rather than guessing at what attributes are appropriate for each role.

FAQ

Frequently asked questions

An enumerated attribute is one that has a fixed set of permitted values defined explicitly by the HTML specification rather than accepting arbitrary content. The input type attribute is the most common example: its permitted values are hidden, text, search, tel, url, email, password, date, month, week, time, datetime-local, number, range, color, checkbox, radio, file, submit, image, reset, and button. Any other value causes the browser to use the missing-value default, which for input type is text. Validators report enumerated attribute values not in the permitted set as errors so you can catch typos and misuse before they reach production.

Boolean attributes in HTML5 are activated by their mere presence on an element and deactivated by their absence. The value assigned to the attribute does not matter at all: the presence of the attribute name is sufficient to enable the boolean state it represents. Valid boolean attribute syntax includes the bare attribute name (disabled), an empty string value (disabled=""), or the name as its own value (disabled="disabled"). Invalid forms that should be avoided include disabled="true" or disabled="false". Despite the apparent meaning of the word "false", disabled="false" still enables the disabled state because the attribute is present at all.

A data-* attribute name must start with the prefix "data-" followed by at least one character in the custom portion. The custom part must not contain uppercase ASCII letters from A through Z, must not contain colons, and must not start with the string "xml". The name data-userId is invalid because of the uppercase I; data-user-id is valid and accesses as dataset.userId in JavaScript. The HTML spec enforces these rules so that the dataset JavaScript API can perform consistent camelCase conversion between HTML attribute names and JavaScript property names without ambiguity.

Custom attributes must use the data-* naming convention to be considered valid HTML. Adding attributes without the data- prefix, such as customattr="value" on a div, is an HTML spec violation that validators will flag as an unknown attribute error. Framework template syntax used by Vue, Angular, React, and similar systems that uses non-standard attribute patterns is not a concern in the rendered HTML output reaching the browser because these attributes are processed at compile or render time and removed before the HTML is served. If they appear in the final output, that indicates a framework rendering bug.

The WAI-ARIA specification defines a set of global states and properties that can be applied to any HTML element regardless of its role: aria-atomic, aria-busy, aria-controls, aria-current, aria-describedby, aria-details, aria-disabled, aria-dropeffect, aria-errormessage, aria-flowto, aria-grabbed, aria-haspopup, aria-hidden, aria-invalid, aria-keyshortcuts, aria-label, aria-labelledby, aria-live, aria-owns, aria-relevant, and aria-roledescription. Other aria-* attributes are role-specific and are only valid on elements with the matching role or implicit role; using them on incompatible elements produces a validation error.

If an input type attribute value is not in the HTML spec's permitted enumerated set of values, the browser treats the input as type="text" silently using the missing-value default behavior. The input renders as a plain text field rather than the intended control type. This means a misspelled type like "sumbit" or "emial" produces a text field instead of the intended submit button or email input, which is a significant functional bug that affects users but does not trigger any browser error or console warning. HTML validation catches the invalid value immediately and points to the specific element involved.

ARIA attributes are generally not required on native HTML elements that already carry their implicit ARIA semantics through the element type itself. A button element has an implicit role of button by default, so adding role="button" explicitly is redundant but not an error. Required ARIA attributes apply when an ARIA role is explicitly assigned: an element with role="combobox" requires the aria-expanded attribute and the aria-controls attribute according to the WAI-ARIA specification. The spec defines the required states and properties for each role, and validators check that required attributes are present when the role demands them.

The most common reasons a validator flags aria-label are: the element has its own visible text content that already provides an accessible name and aria-label is redundant or conflicting with it; the element does not support aria-label according to its role; or the aria-label value is empty (an empty aria-label removes the accessible name entirely, which is rarely intentional). Read the full validator error message to identify which of these conditions applies to your specific case. Remove aria-label if the element already has accessible text, or fix the empty value if that is the issue.

A single validation pass surfaces every attribute error in the document at once because the validator examines all attributes on all elements during one analysis. Look through the error list for messages mentioning attribute names, invalid values, unknown attributes, or ARIA-related issues. The validator reports each error with its line and column location so you can navigate directly to the relevant element in your source. For very large documents with many attribute errors, work through them in document order to maintain context as you fix each one.