HTML
The markup layer every web page is built on: document skeleton, semantic elements, forms, accessibility, head metadata, and media. Interviewers lean on HTML to check whether you reach for the right native element and its built-in behavior before reinventing it in JavaScript.
on this pageshowhide
guide
overview
~1 minHTML is the markup layer every page starts from. Interviewers use it to test one habit above the rest: do you reach for the native element, with the behaviour the browser already ships, before rebuilding it from a `div` and JavaScript? Getting that wrong costs keyboard support, form submission, screen-reader output and search visibility at once, so HTML questions are rarely about syntax and mostly about consequences. The hub follows a page from file to finished experience. [Document structure](/topics/fe-html-document-structure) covers what the browser does with your file before anything paints: the doctype, the head, parser error recovery and script loading. [Semantic elements](/topics/fe-html-semantics) is about choosing elements for meaning — landmarks, heading rank, lists, tables — and knowing when a `div` is the honest choice. [Forms and inputs](/topics/fe-html-forms) is where HTML carries the most built-in behaviour: controls, labels, validation, submission and autofill. [Accessibility and ARIA](/topics/fe-html-accessibility) is the explicit layer on top of native semantics: roles, names, live regions and focus. [Metadata and SEO](/topics/fe-html-metadata-seo) treats the head as crawlers, link previewers and devices read it, and [media and embedding](/topics/fe-html-media-embedding) covers images, video and frames, where accessibility and page weight meet. Junior rounds check that you know what an element or attribute means. Middle and senior rounds hand you flawed markup — a clickable `div`, an input with no label, a lazy-loaded hero image — and expect you to name what the user loses and the smallest native fix. The hardest questions sit at the edges, where HTML turns into a performance, security or server-rendering decision. Start with document structure and semantics, then forms. Accessibility makes far more sense once you know what native elements already give you, and the metadata and media sections build on all three.
primer
### Markup has more than one reader The browser's renderer, the accessibility tree, search crawlers, link-preview scrapers and password managers all read the same markup, and several of them never run your JavaScript or apply your CSS. Choosing an element is a statement to every one of them. A strong HTML answer names which reader is affected — the screen-reader user, the crawler, the autofill engine — instead of stopping at "it's more semantic". ### Native elements come with behaviour A `button`, a link with `href`, a `label`, a `form` or a `dialog` brings focus handling, keyboard activation, a role and, where relevant, submission. A `div` brings none of it. Interviewers check whether you know that list well enough to price a replacement. The default position is native first; custom widgets and ARIA are for the gaps the platform genuinely leaves. ### Meaning and appearance are separate Heading rank describes structure, not font size; `strong` describes importance, not boldness; a table holds data with rows and columns, not a layout grid. CSS can make any element look like any other, so pick the element for what the content is and restyle it afterwards. The test interviewers reach for: would the page still make sense with its stylesheet removed? ### The parser forgives, and that hides bugs The HTML parser does not reject a document. Unclosed tags, misplaced elements and stray slashes are repaired by precise recovery rules, so the DOM can differ from the source you wrote without any error appearing. Scripts, styles and assistive technology all see the repaired tree, not your file, which explains a whole family of "why is my element in the wrong place" questions. ### Document order decides what happens first The browser reads top to bottom and commits to decisions as it goes: which encoding to use, whether a stylesheet holds back the first paint, when a script is fetched and run, which image candidate to download. Position plus a handful of attributes — `defer`, `async`, `media`, `loading`, `fetchpriority` — are the levers, and many performance questions are really questions about this order. ### ARIA changes what is announced, not what happens Roles, states and properties rewrite how an element is exposed to assistive technology. They add no keyboard support, no focus handling and no behaviour. That is why misapplied ARIA is worse than none, and why accessibility questions turn on whether the promises a role makes are actually kept in script. ### Some markup is really a network or security setting Some attributes change requests and privileges rather than content: `srcset` and `sizes` decide which file downloads, `loading` delays a fetch, `sandbox` strips a frame's capabilities, and a form's `method` decides whether values end up in a URL. Senior questions often start here, because the fix looks like markup while the consequence is bandwidth, privacy or origin isolation.
- Void element
- An element that can never have content or an end tag, such as br, img, input and meta. A trailing slash on it is allowed but means nothing to the parser.
- Content model
- The rule for what an element may contain, expressed in categories such as flow and phrasing content. Breaking it is what triggers parser repairs and invalid nesting.
- Quirks mode
- A rendering mode that emulates old browser behaviour for pages without a proper doctype. Standards mode is what modern layout assumes.
- Render-blocking resource
- A resource the browser must fetch and process before it paints anything, typically a stylesheet in the head or a classic script without defer or async.
- Landmark
- A page region exposed to assistive technology with a role such as main, navigation or banner, so users can jump between regions instead of reading linearly.
- Accessibility tree
- The browser's parallel structure of roles, names and states, derived from the DOM and ARIA, that screen readers and other assistive technology query.
- Implicit role
- The ARIA role an element exposes by itself, like button for button or list for ul, with no role attribute written.
- Accessible name
- The short label assistive technology announces for an element, computed from sources such as its text, a label, alt text or ARIA attributes.
- Live region
- An element whose content changes are announced by screen readers without moving focus, used for status messages and errors.
- Constraint validation
- The browser's built-in form checking driven by attributes such as required, pattern, min and type, with a script API for querying and reporting validity.
- Autocomplete token
- A standardised value of the autocomplete attribute, such as email or postal-code, that tells the browser what a field holds so autofill fills it correctly.
- Art direction
- Serving a different image — a new crop or composition — at different viewport sizes, rather than the same image at different resolutions.
- Canonical URL
- The address a page declares as authoritative for its content, so search engines consolidate duplicate URLs onto one result.
- Open Graph
- A set of meta properties in the head that link-preview scrapers read to build a shared link's title, description and image.
- JSON-LD
- A JSON format for linked data, embedded in a non-executing script block, that describes a page's entities to crawlers, usually with schema.org vocabulary.
- Sandboxed iframe
- A frame whose document starts with most capabilities revoked, each restored only by an explicit token in the sandbox attribute.
### From bytes to a page Follow one document from the server. The parser scans the first bytes for an encoding, reads the doctype to choose a rendering mode, and builds the DOM, repairing broken nesting as it goes. Along the way it discovers resources: stylesheets that hold back painting, scripts that pause parsing or wait for it depending on their attributes, and images whose candidate the browser picks before layout is known. From the finished DOM the browser derives two structures — the render tree, combined with CSS, and the accessibility tree, built from each element's implicit role and name plus any ARIA on top. ### Where the sections attach Document structure owns that first pass. Semantics decides what lands in the accessibility tree without a single ARIA attribute; accessibility covers what you add when native elements run out, and how names, live updates and focus behave. Forms are where the DOM turns into behaviour the browser runs for you — validation, submission, autofill. Metadata and media hang off the same pass but serve other readers: crawlers and previewers read the served HTML, often without running scripts, and image attributes steer the network. A single form field shows several sections meeting: ```html <form method="post" action="/account"> <label for="email">Work email</label> <input id="email" name="email" type="email" autocomplete="email" required aria-describedby="email-hint"> <p id="email-hint">Receipts go to this address.</p> <button>Save</button> </form> ``` The `label` gives the field its name and a larger click target; `type` and `required` feed constraint validation; the autocomplete token feeds autofill; `aria-describedby` adds a hint read after the name; `name` is what puts the value into the submission; and a `button` inside a form submits by default. Remove any one line and a different section of this hub explains what broke.
- Document Structure →
What the browser does with the file before painting: doctype, head order, parser recovery and script loading. Everything else assumes it.
- Semantic Elements →
Choosing elements for meaning — landmarks, heading rank, lists, tables — which decides most of what assistive technology receives for free.
- Forms and Inputs →
The part of HTML with the most built-in behaviour: labels, input types, validation, submission and autofill.
- Accessibility and ARIA →
ARIA, accessible names, live regions and focus, best learned once you know what native elements already provide.
- Media and Embedding →
Images, video and frames, where attributes decide page weight, layout stability, alt text quality and iframe privileges.
- Metadata and SEO →
The head as crawlers and link previewers read it: meta tags, share cards, canonical and robots directives, structured data.
Building a button or link from a
divand patching in a role, then forgetting the keyboard activation and focus the native element gave for free — see the clickable-div question.Choosing a heading level for its font size; rank is structure, and skipped or out-of-order levels break the outline screen-reader users navigate by.
Treating
placeholderas a label, or atitletooltip as an accessible name; one vanishes while the user types, the other is unreliable for many users.Adding
roleoraria-*attributes that promise behaviour the script never delivers, which leaves the control worse off than unannotated markup.Putting
loading="lazy"on the above-the-fold hero image, delaying the most visible paint to postpone a download the page needed anyway.Expecting crawlers and link previewers to see meta tags written into the head by client-side JavaScript; put them in the HTML the server sends.
Blocking a page in
robots.txtto get it out of search results; a crawler that never fetches the page never sees itsnoindex.Believing
<div />closes the div, or that anh1nested in asectionis demoted; browsers do neither.Calling a frame isolated when its sandbox combines
allow-scriptswithallow-same-originfor content served from your own origin.
HTML no longer has version numbers. The specification browsers implement is the WHATWG HTML Living Standard, updated continuously; "HTML5" survives as a label for the generation of features that arrived with it — sectioning elements, new input types, `video` and `audio`, `canvas`. If an interviewer asks which version you know, the accurate answer is the living standard, with support checked per feature rather than per version. A few pieces of history still come up: - **XHTML habits.** Self-closing slashes came from XHTML's XML syntax. The HTML parser ignores them, which is why `<div />` stays open. - **The outline algorithm.** HTML5 once described headings being re-ranked by their nesting in sectioning elements. Browsers never implemented it and it was removed from the standard, so explicit heading ranks are what count. - **Doctypes.** HTML 4 and XHTML doctypes referenced DTDs; `<!DOCTYPE html>` exists only to select standards mode. - **Recent additions.** Features such as `dialog`, the `inert` and `popover` attributes, and the `search` element moved behaviour into markup that used to need scripts. Check support for the newest before relying on them in an answer about production code. This guide assumes the current living standard and evergreen browsers.
explore
- Document Structure26 questions
- DOCTYPE and Rendering Modes5 questions
- Head Essentials and Ordering5 questions
- Parsing Model and Error Recovery5 questions
- Script Loading Attributes5 questions
- Global Attributes and data-*6 questions
- Semantic Elements31 questions
- Sectioning and Landmarks5 questions
- Heading Hierarchy5 questions
- Text-Level Semantics6 questions
- Lists Done Right5 questions
- Data Tables5 questions
- Content Models and When div/span Are Right5 questions
- Forms and Inputs32 questions
- Input Types and Attributes5 questions
- Labels and Fieldsets5 questions
- Select, Textarea, and Other Controls5 questions
- Constraint Validation API6 questions
- Submission Semantics and FormData6 questions
- Autofill and autocomplete Tokens5 questions
- Accessibility and ARIA30 questions
- The Native-First Rule5 questions
- Roles, States, and Properties5 questions
- aria-label vs labelledby vs describedby5 questions
- Accessible Name Computation5 questions
- Live Regions and Announcements5 questions
- Focus Management and tabindex5 questions
- Metadata and SEO26 questions
- Meta Tags and Viewport5 questions
- Open Graph and Twitter Cards5 questions
- Canonical and Robots Directives6 questions
- Structured Data with JSON-LD5 questions
- Icons and Manifest Links5 questions
- Media and Embedding29 questions
- srcset and sizes5 questions
- picture and Art Direction5 questions
- loading, decoding, and fetchpriority4 questions
- Alt Text and Figures5 questions
- video and audio Elements5 questions
- iframe Embedding and sandbox5 questions
questions
174 · 6 sectionsWhat does the line <!DOCTYPE html> at the top of an HTML file do, and what happens if you leave it out?
basics
~20 sIn HTML, what does the data-* attribute family give you that inventing your own attribute such as userid does not?
basics
~20 sdata-* is HTML's sanctioned slot for custom data: it is valid markup, it can never collide with an attribute the language adds later, and browsers expose it to scripts through element.dataset. An invented attribute such as userid gets none of those guarantees.
Why must <meta charset="utf-8"> appear at the very start of an HTML page's <head>, and what goes wrong if it comes later?
basics
~20 sBrowsers pre-scan only the first 1024 bytes of an HTML file for the encoding declaration, so <meta charset="utf-8"> must come first inside <head>. Declared later, the browser guesses an encoding and may have to reparse the document or render garbled text.
In HTML, how do a plain <script src>, a <script defer src>, and a <script async src> differ in when the file is downloaded, when it executes, and whether execution order is guaranteed?
basics
~20 sA plain <script src> pauses HTML parsing to download and run. defer downloads in parallel and runs after parsing, in document order. async downloads in parallel and runs the moment it arrives, in unpredictable order.
What does the lang attribute on the <html> element actually change in a browser, and when should you set lang on an element deeper in the page?
basics
~20 slang declares the document's natural language with a BCP 47 tag, and it drives screen-reader pronunciation and voice choice, hyphenation and line breaking, font and glyph selection, the spellcheck dictionary, and translation offers. Set it again on any element whose content is in a different language.
In HTML, when is a <div> or a <span> the right element to use, and how do you choose between the two?
basics
~20 sReach for div or span only when no element with meaning fits — they carry no semantics. div is a flow-content container for blocks of content; span is a phrasing-content container for a run of text inside a line.
In HTML, what decides whether a piece of text should be an <h2> or an <h3>, and why is "it renders at the size the design wants" the wrong reason to choose one?
basics
~20 sHeading rank encodes document structure: an h2 is a top-level section, an h3 a subsection of the h2 above it. Visual size is CSS's job, so choose the rank the outline needs and restyle it.
In HTML, which elements are allowed as direct children of <ul> and <ol>, and where must a nested sublist be placed?
basics
~10 sOnly <li> elements may be direct children of <ul> and <ol>, plus the script-supporting elements <script> and <template>. A nested sublist belongs inside the <li> it hangs off, never between two <li> elements.
Which HTML elements expose implicit landmark roles, and what do landmarks give a screen-reader user that a page built from <div>s does not?
basics
~20 sA top-level <header>, <nav>, <main>, <aside>, <footer>, <search> and a named <form> expose the banner, navigation, main, complementary, contentinfo, search and form landmark roles. Screen readers list landmarks so users jump between regions instead of reading everything.
In HTML, what is the difference between <strong> and <b>, and between <em> and <i>, and what does choosing correctly actually change?
basics
~20 sThe strong element marks importance and em marks stress emphasis that changes a sentence's meaning. The b and i elements set text apart without importance: b draws attention, i signals an alternative voice such as a foreign phrase or technical term.
The HTML autocomplete attribute accepts more than "on" and "off". What is its token vocabulary, and what would you put on the name, email and address inputs of a checkout form?
basics
~20 sautocomplete takes a defined vocabulary of field-name tokens — name, email, tel, street-address, address-level2, postal-code, country, cc-number — not just on/off. The token tells the browser what a field means so autofill fills it correctly.
In a plain HTML form, one input carries required and another carries pattern="[0-9]{4}". What exactly does the browser do when the user presses the submit button while those constraints are not satisfied?
basics
~20 sThe browser blocks submission: no submit event fires and no request goes out. It focuses the first invalid control, shows a built-in message bubble beside it, and fires a non-bubbling invalid event on each failing control.
What do you gain by setting an HTML <input> to type="email" instead of leaving it as type="text"?
basics
~20 stype="email" makes the browser reject values that are not shaped like an address, switches mobile keyboards to an @-and-dot layout, and helps password managers and autofill recognise the field. It never checks that the address exists.
In an HTML form, what are the two ways to associate a <label> element with an input, and what does that association actually give the user?
basics
~20 sTwo ways: an explicit label whose for attribute holds the input's id, or a label that wraps the input. Either one names the control for assistive technology and makes clicking the label text focus or toggle that control.
When a browser submits a plain HTML form, which controls actually end up in the submitted data, and what excludes a control from it?
basics
~20 sOnly enabled controls that have a non-empty name attribute are submitted. Missing name, disabled, and unchecked checkboxes or radios all send nothing; readonly fields are still sent, and a checkbox with no value attribute sends the string "on".
In HTML and ARIA, what is an element's accessible name, and what does the browser compute it from for `<button>Save</button>` and `<img src="logo.png" alt="Acme home">`?
basics
~20 sAn element's accessible name is the short label assistive technology announces for it. The browser computes it per element type: a button's name comes from its own text content, an image's from its alt attribute.
In HTML, what do tabindex="0", tabindex="-1", and a positive value such as tabindex="3" each do to an element?
basics
~20 stabindex="0" puts an element in the tab order at its DOM position; a negative value such as -1 makes it focusable by script or click but never by Tab; a positive value jumps it ahead of everything else and wrecks the order.
A toolbar button in your HTML contains only an <svg> icon and no text. What are your options for giving it an accessible name, and which would you choose?
basics
~20 sGive the button an accessible name with aria-label="Delete", with visually hidden real text inside it, or with aria-labelledby pointing at existing on-screen text. Hide the decorative icon with aria-hidden="true" so it adds nothing. A title tooltip alone is not enough.
In ARIA, what is the difference between aria-live="polite" and aria-live="assertive" on a live region, and which of the two do role="status" and role="alert" imply?
basics
~10 saria-live="polite" queues the announcement until the screen reader finishes what it is saying; aria-live="assertive" interrupts immediately. role="status" implies polite, role="alert" implies assertive, and both imply aria-atomic="true".
In web accessibility, the "first rule of ARIA use" is quoted constantly in interviews. What does the rule say, and what does following it look like in real markup?
basics
~20 sThe first rule of ARIA is to not use ARIA when a native HTML element already provides the semantics and behaviour you need. Reach for button, a with href, input and label first; add ARIA only to fill real gaps.
In HTML, what does `<link rel="canonical">` tell a search engine, and what is a self-referencing canonical?
basics
~20 sA canonical link names the URL you consider authoritative for content that is reachable at several addresses, so duplicates consolidate onto one page instead of competing. A self-referencing canonical points a page at its own clean URL.
A responsive page opens on a phone rendered at desktop width and zoomed out, and its media queries appear to be ignored. What does `<meta name="viewport" content="width=device-width, initial-scale=1">` change, and why is the page broken without it?
basics
~20 sWithout a viewport meta tag, phone browsers lay a page out in a pretend wide viewport (about 980 CSS pixels) and shrink the result to fit the screen. width=device-width, initial-scale=1 makes the layout width match the device, so width-based media queries see real sizes.
When someone pastes a link to your page into Slack or a social feed, which Open Graph meta tags decide the preview's title, description and image, and why are Open Graph tags written with property= instead of name=?
basics
~10 sOpen Graph tags in the head supply the preview: og:title, og:description and og:image, plus og:url and og:type. They use property= because Open Graph is an RDFa vocabulary, unlike Twitter's twitter:* tags, which use name=.
What does a `<script type="application/ld+json">` block in an HTML page contain, and what does the browser do with its contents when it parses the page?
basics
~20 sA script tagged type="application/ld+json" holds JSON-LD data describing the page's entities, usually with schema.org vocabulary. The browser treats it as an inert data block: never executed, never displayed. Machines such as search crawlers read it.
A URL is listed under `Disallow` in robots.txt and the page also serves `<meta name="robots" content="noindex">`. Why can that URL still turn up in search results?
basics
~20 srobots.txt controls crawling, not indexing. A crawler that obeys the Disallow never fetches the page, so it never reads the noindex directive inside it — while the URL itself, discovered from links elsewhere, can still be indexed without a description.
In HTML, what should an img element's alt attribute say, and when is alt="" (an empty value) the correct choice?
basics
~20 sAlt text states the image's purpose in its context, not its appearance — what a reader would lose if the image never rendered. Purely decorative images take alt="" so assistive technology skips them instead of announcing a file name.
Why should an HTML <img> carry width and height attributes even when CSS controls its rendered size, and what does the browser do with those two numbers?
basics
~20 sThe width and height attributes give the browser the image's aspect ratio before the file arrives, so it can reserve a correctly proportioned box during the first layout instead of collapsing the space and shoving content down when the image lands.
In an HTML <picture> element, which child actually renders the image, and where do attributes like alt, width, height and class belong?
basics
~20 sThe img renders; picture and source only offer candidates to it. So alt, width, height, class and loading all belong on the img, which must be the last child. A picture with no img displays nothing at all.
On an HTML <img>, what do the srcset and sizes attributes do, and what is the difference between a w descriptor and an x descriptor inside srcset?
basics
~20 ssrcset lists interchangeable files for one image: a w descriptor states a file's intrinsic pixel width, an x descriptor targets a device pixel ratio. sizes declares how wide the image will render, which the browser needs to choose among w candidates.
What does adding the sandbox attribute to an HTML <iframe> do, and how do tokens such as allow-scripts and allow-forms change that?
basics
~20 sThe sandbox attribute revokes an iframe's capabilities by default: scripts, form submission, popups, top-level navigation, downloads and modal dialogs are blocked, and the frame runs in a unique opaque origin. Each allow-* token grants one capability back.