W3docs

HTML Autofocus Attribute

On this page, you can find information about the HTML autofocus attribute, see its usage, the elements that it applies to,as well as try different examples.

The HTML autofocus attribute is a boolean attribute that tells the browser to automatically move keyboard focus to an element as soon as the page (or the containing dialog) is loaded. The user can start typing or interacting with that element immediately, without clicking or tabbing to it first.

The autofocus attribute was introduced in HTML5 and is now supported by all modern browsers (Chrome, Firefox, Safari, and Edge have shipped it broadly since around 2020).

This page covers the syntax, the elements it applies to, the most common modern use case (a <dialog>), and the accessibility trade-offs you should weigh before using it.

Syntax

autofocus is a boolean attribute, so its mere presence enables it — no value is needed.

<input autofocus>
Applies toAny focusable HTML element. It is most commonly used on form controls such as <input>, <button>, <select>, and <textarea>. A <dialog> opened with showModal() and an open <details> element also participate in autofocus handling.

Only one autofocus per document

The autofocus attribute may be set on only one element per document. If you add it to several elements, browsers apply it to the first element with the attribute in document order and ignore the rest. So you cannot use autofocus to focus more than one field at once — focus is, by definition, a single point.

Basic example

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Title of the document.</title>
  </head>
  <body>
    <h1>Example of the HTML "autofocus" attribute.</h1>
    <form action="#">
      Name: <input type="text" name="fname" autofocus /><br />
      Surname: <input type="text" name="lname" /><br />
      <input type="submit" />
    </form>
  </body>
</html>

When the page loads, the "Name" field is focused and the cursor blinks there, ready for input.

Autofocus on other elements

autofocus is not limited to text inputs. It works on any focusable control. The browser focuses the element; for a <select> or <button> that means it becomes highlighted and keyboard-ready, and for a <textarea> the caret is placed inside it.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Autofocus on different controls</title>
  </head>
  <body>
    <!-- A button can receive autofocus -->
    <button type="button" autofocus>Start here</button>

    <!-- A select can receive autofocus -->
    <label>Country:
      <select name="country">
        <option>United States</option>
        <option>Germany</option>
        <option>France</option>
      </select>
    </label>

    <!-- A textarea can receive autofocus -->
    <label>Message:
      <textarea name="message" rows="4"></textarea>
    </label>
  </body>
</html>

Remember the single-autofocus rule: only the <button> above will be focused, because it is the first element carrying the attribute.

Autofocus in a <dialog> (most common modern use)

The clearest, most defensible use of autofocus is inside a modal <dialog>. When a user deliberately opens a dialog, sending focus to the first relevant control inside it is expected behavior — it keeps the keyboard user inside the dialog and ready to act.

<!DOCTYPE html>
<html lang="en">
  <head>
    <title>Dialog with autofocus</title>
  </head>
  <body>
    <button id="openBtn">Open dialog</button>

    <dialog id="myDialog">
      <form method="dialog">
        <p>
          <label>Your name:
            <input type="text" name="name" autofocus />
          </label>
        </p>
        <button value="ok">OK</button>
        <button value="cancel">Cancel</button>
      </form>
    </dialog>

    <script>
      const dialog = document.getElementById("myDialog");
      document.getElementById("openBtn")
        .addEventListener("click", () => dialog.showModal());
    </script>
  </body>
</html>

Because the dialog opens in response to a user action, moving focus into it is not disorienting — it is exactly what the user asked for. This is why autofocus on a dialog control is far safer than autofocus on a field in a freshly loaded page.

When (and when not) to use autofocus

Autofocus saves a click and signals where to start, but it also seizes control of the keyboard from the user. Use it when:

  • The page or view exists for the sole purpose of that one input — a dedicated search page, a login screen, or a single-question step.
  • Focus moves in response to a user action, such as opening a modal <dialog>.

Avoid it when:

  • The element sits below the fold or partway down a content-heavy page. Focusing it forces the browser to scroll, which is jarring and skips the content above.
  • The page has meaningful content the user should read first (an article with a comment box, for example). Autofocusing the comment box yanks the reader past the article.

Accessibility considerations

autofocus directly affects assistive-technology users, so handle it carefully.

  • Screen-reader disruption. Screen readers normally begin reading from the top of the document. When focus is forced onto an element mid-page, the reader may jump straight to that control and silently skip the heading, navigation, and intro — the user lands "mid-page" with no context about where they are.
  • WCAG 2.4.3 (Focus Order). This success criterion requires that focus order preserve meaning and operability. Jumping focus to an arbitrary control on load can violate the user's expected reading and tab order. Reserve autofocus for cases where the focused element genuinely is the logical starting point.
  • Unexpected context shift. Suddenly moving focus and scrolling the viewport can disorient users with cognitive disabilities or low vision, who may not notice that the page moved.

A practical rule: only autofocus an element when focusing it does not scroll the page and when that element is unambiguously the first thing the user wants to do.

Mobile caveat

Several mobile browsers intentionally ignore autofocus on page load. On iOS, mobile Safari does not raise the on-screen keyboard or move focus automatically from a page load, and Chrome on Android behaves similarly. This is an OS-level UX decision: auto-opening the virtual keyboard would cover content, shift the layout, and surprise the user before they have decided to type.

There is no reliable "force it anyway" workaround on these platforms, and trying to fake it with JavaScript (element.focus() on load) is also blocked unless it happens inside a user-gesture handler. The accepted approach is to focus in response to a tap — for example, calling .focus() when the user opens a dialog or taps a "search" button — which is exactly the dialog pattern shown above.

Browser compatibility

autofocus is part of the HTML Living Standard and enjoys broad support: Chrome, Edge, Firefox, and Safari have implemented it for years, with the modern (any-element) behavior available across these browsers since roughly 2020. The mobile keyboard restriction described above is a deliberate platform behavior, not a lack of support.

Practice

Practice
What is true about the HTML autofocus attribute according to the specified URL?
What is true about the HTML autofocus attribute according to the specified URL?
Was this page helpful?