Technology interview warm-up
HTML interview questions and answers hub with coding prompts, concept questions, follow-ups, and common mistakes. Practice concise answers first, then expand into Study Plans, guides, and Company Prep.
On this page
Popular clusters
Short answers
HTML is the markup language browsers parse to create the structure and meaning of a web document. It describes content with elements such as headings, links, images, forms, tables, and landmarks. HTML quality affects accessibility, SEO, browser defaults, and how safely CSS and JavaScript can build on the page.
Build a basic document →The DOM is the browser-created object tree that represents the parsed document. JavaScript reads and changes the DOM, and CSS selectors match elements in it for styling. The live DOM can differ from the original HTML source after parsing fixes or script updates.
Review the DOM →A tag is the written markup token, such as an opening or closing marker. An element is the full parsed node, including the tag, attributes, content, and browser-defined meaning. Void elements such as img do not have closing tags, which is a common edge case.
Review HTML tags →A valid document starts with a doctype, an html element with a language, a head for metadata, and a body for visible content. The head should include charset, viewport, title, and other metadata needed by browsers and crawlers. Missing structure can still render, but it creates ambiguity for accessibility, mobile layout, and SEO behavior.
Practice document structure →The head contains document metadata, resource hints, styles, scripts, titles, descriptions, and viewport settings. The body contains the content and controls users interact with. Putting visible content or structural landmarks in the head is invalid and can produce unexpected parsing behavior.
Review the head element →Semantic elements describe the meaning or role of content, such as header, nav, main, article, section, footer, button, and form. They give browsers and assistive technology useful information before any custom scripting. Replacing semantic controls with generic div elements often creates extra keyboard and accessibility work.
Review semantic elements →div is a generic block-level container, while span is a generic inline container. Neither carries semantic meaning by itself. They are useful for grouping only when a more meaningful element is not available.
Compare div and span →Block elements normally start on a new line and occupy available width, while inline elements flow inside text. The distinction affects layout, spacing, and how elements accept dimensions. CSS can change display behavior, but the semantic choice should still match the content meaning.
Review block and inline →An anchor creates navigation when it has a useful href. It should describe the destination with link text that makes sense out of context. Use a button instead when the action changes state on the current page rather than navigating.
Review anchors →href defines the target URL or fragment for an anchor or linked resource. A missing or fake href can break expected link behavior, keyboard navigation, and browser features such as opening in a new tab. For external links, security and referrer behavior may also matter.
Review href behavior →Alt text should describe the purpose of an informative image. Decorative images usually need empty alt text so assistive technology can skip them. If an image is inside a link, the alt text may need to describe the link action rather than the visual pixels.
Review image alt text →A form groups controls and can submit name/value pairs to a server or be handled by JavaScript. Native controls provide keyboard behavior, labels, validation hooks, and browser defaults. The form still needs server-side validation because client-side constraints can be bypassed.
Build labeled forms →A label gives a form control a durable accessible name and a larger clickable target. Placeholder text disappears as users type and is not a reliable replacement for a label. Placeholders are best used as examples or hints, not as the only field name.
Review placeholders →Native validation uses attributes such as required, type, min, max, pattern, and minlength. The browser can block common invalid submissions and expose useful constraint states. It improves user experience, but server validation remains the real trust boundary.
Practice validation →Lists should represent grouped items where order or grouping matters, and navigation should use nav when it identifies a major navigation region. Link lists are often appropriate for menus because they expose both grouping and navigation semantics. Overusing lists for purely visual layout can make the markup noisy.
Practice navigation markup →Data tables need table markup, header cells, and clear relationships between headers and data cells. Captions and scope attributes help users understand row and column meaning. Tables used only for layout create misleading relationships and should be avoided.
Build accessible tables →A production page usually needs charset, viewport, title, description, canonical when needed, and relevant social metadata. Metadata helps browsers render correctly and helps crawlers understand the page. Missing viewport metadata is a common mobile rendering failure.
Review head metadata →data-* attributes store custom, non-sensitive metadata on elements. They are useful for testing hooks, progressive enhancement, and connecting markup to scripts without inventing invalid attributes. They should not become a replacement for semantic attributes or server-trusted data.
Review data attributes →An iframe embeds another browsing context inside the page. It is useful for third-party content, isolated documents, maps, videos, and sandboxed experiences. It needs a meaningful title and careful sandbox, permissions, loading, and security choices.
Review iframes →srcset provides candidate image resources, and sizes tells the browser how much layout width the image will occupy. The browser uses that information with device characteristics to choose an efficient image. Wrong sizes values can make the browser download images that are too large or too blurry.
Review responsive images →Browsers parse HTML into tokens and build the DOM while applying error-recovery rules. Invalid nesting can be corrected into a different DOM than the source appears to describe. Debugging markup issues often means inspecting the live DOM, not only the source file.
Review parsing behavior →ARIA roles should be used when native HTML cannot express the needed role, state, or relationship. Native elements are usually better because they include built-in keyboard and accessibility behavior. Misused ARIA can create a worse accessibility tree than plain semantic HTML.
Review ARIA roles →Shadow DOM provides an encapsulated DOM tree for a component. It can isolate markup and styles from the main document while still exposing slots and public component behavior. Accessibility, focus, and styling hooks still need deliberate design.
Review Shadow DOM →The dialog element can provide native modal semantics and focus handling support. A usable dialog still needs a clear name, predictable opening focus, escape behavior, and focus restoration. A visually correct overlay is incomplete if keyboard users can reach background content.
Practice dialog accessibility →HTML is the markup language used for web documents, and HTML5 is the common name for modern HTML features and parsing behavior. XHTML is an XML-based syntax with stricter parsing rules. Modern web work usually follows the HTML Living Standard rather than treating HTML5 as a frozen version.
Compare HTML and XHTML →Beginner to experienced
Start with document structure, common elements, links, images, forms, labels, lists, metadata, and the DOM. The goal is to understand what native markup gives the browser before adding CSS or JavaScript.
Move into accessibility trade-offs, browser parsing, table relationships, Shadow DOM, native dialogs, iframes, responsive image markup, and production metadata. Experienced answers should connect markup choices to real browser and user behavior.
Semantics + structure
Landmarks such as header, nav, main, aside, and footer divide the page into recognizable regions. They help assistive technology users jump through the page efficiently. Most pages should have one main landmark and meaningful navigation regions.
Review landmarks →Headings create a content hierarchy for scanning, navigation, and accessibility. Heading levels should represent structure, not visual size. Skipping levels for styling can make the page harder to understand through assistive technology.
Build semantic layout →section groups a themed part of a document, usually with a heading. article represents independent content that could stand on its own, such as a post, card, or comment. A generic wrapper should stay a div when there is no meaningful document section.
Review semantic sections →div and span provide grouping without semantic meaning. They are useful for layout hooks, but they do not communicate navigation, button behavior, headings, form relationships, or document regions. Native semantic elements reduce custom accessibility work.
Compare generic elements →The lang attribute tells browsers and assistive technology the language of the document. It affects pronunciation, translation, spell checking, and some typographic behavior. Pages with mixed languages should mark language changes on the relevant elements.
Practice document basics →Use ul for unordered groups, ol for ordered steps or rankings, and dl for name/value descriptions. Lists communicate grouping that screen readers and browsers can expose. Do not use lists only to force visual indentation when the content is not a list.
Review list types →data-* attributes are useful for custom metadata that scripts or tests need to read. They should not replace existing semantic attributes such as href, alt, for, name, or aria-* when those have real meaning. Data attributes are markup hooks, not validation or security boundaries.
Review data attributes →A scannable document has a clear title, meaningful headings, landmarks, descriptive links, and grouped content. The DOM order should match the reading and keyboard order where possible. Visual layout can change, but the markup should still make sense without CSS.
Practice semantic layout →Forms + validation
A label can connect to a control with for and id, or by wrapping the control. This gives the control an accessible name and increases the clickable target. The association should remain stable even when the layout changes.
Build labeled forms →Placeholder text disappears during input and may not be announced as a stable field name. A real label remains available before, during, and after typing. Placeholder text is better used for examples, formatting hints, or optional guidance.
Review placeholders →Input types such as email, url, number, date, and tel give browsers validation hints and mobile keyboard choices. They improve usability when they match the real data being collected. The wrong type can block valid input or create a poor mobile experience.
Practice input validation →Attributes such as required, minlength, maxlength, min, max, pattern, and type define browser-side constraints. They expose validity state and can block invalid submissions. Server validation is still required because browser constraints are user-experience helpers, not trusted enforcement.
Build validation states →Form errors should be visible, specific, and connected to the affected control. Use nearby text and aria-describedby when the relationship is not already clear. Color alone is not enough because users may miss the state or use assistive technology.
Practice form errors →Related radio buttons and checkboxes should be grouped with fieldset and legend when they share a prompt. The legend gives the group a clear accessible name. Without grouping, users may hear each option without the question it answers.
Practice grouped controls →The default method is GET when no method is specified. GET appends form data to the URL, which is useful for search-like actions but wrong for sensitive or state-changing submissions. POST is usually the better fit when the form changes server state.
Review form methods →A real button has native role, focus, activation, disabled, and form submission behavior. A div with click handling does not provide those behaviors by default. Rebuilding button behavior manually is easy to get wrong for keyboard and assistive technology users.
Practice form controls →Accessibility + ARIA
Add ARIA when native HTML cannot express the role, state, or relationship you need. Native elements should come first because they already include expected keyboard and accessibility behavior. Incorrect ARIA can make an accessible tree less accurate than plain HTML.
Review ARIA roles →An accessible name is the name assistive technology exposes for a control or landmark. It can come from text content, labels, alt text, aria-label, aria-labelledby, or other naming rules. Missing or misleading names make controls hard to operate even when they are visible.
Practice accessible names →When an image is inside a link, the alt text often becomes the link name. It should describe the destination or action, not just the image appearance. Alt text like "arrow" or "icon" usually fails because it does not explain what happens.
Practice links and images →Use real table markup, header cells, a useful caption when context is needed, and scope or header associations for complex tables. The structure should let users understand row and column relationships. Layout tables should be avoided because they communicate false data relationships.
Build accessible tables →An accessible dialog has a clear name, appropriate modal behavior, predictable initial focus, escape behavior, and focus restoration. Background content should not stay reachable when the dialog is modal. The native dialog element helps, but the interaction still needs careful markup.
Practice dialog accessibility →Tab through the page and confirm that focus order follows the DOM and user task. Every interactive element should be reachable, visible, and operable by keyboard. Positive tabindex values usually create fragile focus order and should be avoided.
Review accessibility checks →An iframe needs a title that explains the embedded content. The title helps users decide whether to enter or skip the embedded context. Security attributes such as sandbox and permissions should also match what the embedded content actually needs.
Review iframes →Start with keyboard navigation, labels, headings, landmarks, alt text, table headers, and form errors. Then inspect the accessibility tree and run automated checks such as Lighthouse or axe. Automated tools are useful, but they cannot prove that the user flow makes sense.
Practice accessibility review →Modern markup scenarios
Native dialog can provide built-in modal behavior and browser semantics. A custom modal must recreate focus trapping, naming, escape behavior, background isolation, and focus restoration. Native support reduces work, but the surrounding interaction still needs testing.
Practice dialog behavior →details and summary provide native disclosure behavior without custom JavaScript. The popover attribute can expose lightweight overlay behavior for supported cases. Native primitives are useful when they match the interaction, but they still need labels, focus behavior, and fallback awareness.
template holds inert markup that can be cloned later, and slot defines insertion points for web component content. They support reusable markup without immediately rendering everything into the main DOM. The trade-off is that composition and accessibility still need explicit contracts.
Review web components →The HTML parser can automatically close or move elements to produce a valid DOM. Source that looks nested one way may become a different live tree. This is especially important around paragraphs, forms, tables, lists, and interactive elements.
Review parsing rules →The input has no durable accessible label. Placeholder text disappears during input and is not a stable field name. Add a label connected with for and id, then keep the placeholder only as optional hint text.
Fix labeled inputs →The linked image gives the link an accessible name of "arrow", which describes the icon rather than the action. The link name should explain the destination or action, such as "View pricing". Image alt text inside links often needs to describe behavior, not pixels.
Practice image links →Data cells need header relationships so users can understand what each value means. Without th, caption, scope, or header associations, assistive technology cannot reliably expose row and column context. The visual grid alone is not enough for non-visual navigation.
Fix table markup →A clickable div lacks native button role, keyboard activation, disabled behavior, and form interaction. Adding JavaScript handlers does not automatically recreate all expected behavior. Use a real button for actions and style it as needed.
Practice native controls →Critical for coding rounds and edge-case discussion.
Build a semantic page layout using header, nav, main, section, article, and footer. Focus on correct landmarks, heading hierarchy, and structure rather than styling or layout hacks so the document outline remains clear…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
The goal is to provide a semantic table that screen readers can navigate, with a clear caption and correct header associations. Add headers with scope, captions, and keyboard considerations; test with screen readers and…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
The success message should only appear after a valid submit, so native validation must be enabled and the form action should target the success section. Consider edge cases like invalid email and required fields; test a…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
Create semantic links and images: use anchor elements with descriptive text, add target/rel when opening new tabs, and include alt text for images. This checks basic accessibility, security, and HTML best practices in o…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
You’re given a simple marketing page that renders fine in the browser, but it’s missing production-grade <head> metadata. Update ONLY the <head> so the page has correct encoding, mobile-friendly viewport beh…
Open HTML coding interview challenge →Critical for coding rounds and edge-case discussion.
Build a signup form using native HTML5 validation: required fields, type constraints, minlength, and pattern. The browser should block invalid submissions without custom JS changes, and existing JS/CSS should remain unt…
Open HTML coding interview challenge →Need more implementation reps? Open the full coding list or follow a study plan.
Frequently tested in explanation-heavy rounds.
Semantic HTML elements expose content roles like navigation, article, main content, and supporting sections. They improve accessibility landmarks, SEO structure, and teammate readability, and the common mistake is repla…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
Understand the DOM as the browser's in-memory tree, how DOM mutations trigger real render work, and what to debug when selectors, timing, or frequent updates go wrong.
Open HTML interview question →Frequently tested in explanation-heavy rounds.
The <meta> tag configures how browsers, crawlers, and social platforms interpret a page, and the real production pitfall is shipping the wrong head metadata and debugging broken previews, indexing, or viewport beh…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
The alt attribute gives an image a text alternative for screen readers, fallback rendering, and search understanding. The real production decision is whether an image is decorative, informative, or functional, because l…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
Use a production accessibility review workflow: semantics first, then keyboard and focus, labels and errors, contrast, manual assistive-tech checks, and automated tooling. The real mistake is treating Lighthouse or axe…
Open HTML interview question →Frequently tested in explanation-heavy rounds.
ARIA roles describe element purpose for assistive technologies. They improve accessibility when native semantics aren't available, but should not replace proper HTML tags. The common mistake is treating ARIA like a shor…
Open HTML interview question →Need more concept coverage? Open the full concepts list or browse company packs.
HTML coverage map
HTML is the structural layer browsers parse into the DOM. Strong interview answers explain how markup gives content meaning before CSS styles it or JavaScript changes behavior.
Practice HTML basic structure →Use headings, landmarks, labels, form controls, table headers, and metadata before adding ARIA or custom scripts. This keeps answers grounded in accessibility, SEO, and native browser behavior.
Build a labeled contact form →Treat HTML5 as modern HTML: the simple doctype, semantic elements, media, native validation, and the living-standard mindset. The interview signal is knowing which browser behavior comes for free.
Review HTML document standards →Do not stop at a validator. Test keyboard flow, labels, focus order, table headers, contrast, screen-reader or accessibility-tree output, then run Lighthouse, axe, and an HTML checker.
Practice accessibility review →Treat modern HTML as browser behavior and progressive enhancement, not a detached trends list.
Use official references for syntax and browser behavior, then practice the same ideas through interview prompts.
HTML behavioral questions usually test how markup decisions improved accessibility, SEO, form clarity, and collaboration outcomes in real product work.
Interview prep context
HTML questions are reviewed for practical browser behavior and interview-ready explanation quality.
Quick answers
Yes. The page starts with beginner and fresher-friendly HTML fundamentals, then moves into experienced-developer topics such as accessibility trade-offs, browser parsing, Shadow DOM, native dialogs, iframes, responsive images, and markup scenarios.
Yes. It covers document structure, semantic elements, landmarks, headings, sections, articles, lists, navigation, language, and when generic div or span markup is not enough.
Yes. It covers labels, placeholders, input types, native validation attributes, form errors, grouped controls, form methods, real buttons, and server-side validation boundaries.
Yes. It covers accessible names, alt text, data tables, ARIA roles, native semantics, keyboard checks, iframe titles, dialog behavior, and quick accessibility testing.
Yes. It covers HTML5-era native behavior, the DOM, head metadata, title and meta tags, viewport behavior, responsive images with srcset, iframe constraints, Shadow DOM, and browser parsing.
Start with the HTML coding preview on this page, then practice basic document structure, labeled contact forms, validation, semantic layout, accessible tables, links, images, lists, and native dialog behavior.
Start with one route first. Then expand into Question Library, Study Plans, and Company Prep only when you need them.
Recommended preparation
Start with the interview preparation guide and shared baseline, then tighten HTML coding, concepts, and follow-up depth.