HTML & CSS Interview Questions (2026)

Semantic HTML means choosing elements for their meaning, not their appearance: nav for navigation, article for self-contained content, button for actions. A div styled as a button can look identical on screen, but the semantic version tells browsers, screen readers, and search engines what the content actually is.

It matters for three audiences. Assistive technology announces landmarks and roles so users can jump straight to the content they want. Search engines read structure when parsing pages. And other developers see intent in the markup itself, which keeps large codebases readable.

Block elements start on a new line and stretch the full width of their container: div, p, section. Inline elements flow within text and take only the space their content needs: span, a, strong. Inline-block flows like inline but respects width, height, and vertical spacing like block.

The practical trap: width and height do nothing on inline elements, and vertical margins are ignored. That's why nav links get display: inline-block the moment they need real padding and dimensions.

Use article for content that stands alone if you lifted it off the page: a blog post, a product card, a comment. Use section for a thematic grouping that belongs to the page, ideally with its own heading. Use div when you need a hook for styling and no semantic element fits.

The self-containment test settles most debates: would this block make sense on its own in an RSS feed? Article if yes, section if it's a chapter of something larger, div if it's pure presentation.

The doctype tells the browser to render the page in standards mode. Without it, browsers drop into quirks mode, an emulation of 1990s behavior where the box model, percentage heights, and inline image gaps all work differently for the sake of ancient pages.

It isn't an HTML element and isn't case-sensitive; it's an instruction to the parser. The HTML5 form is deliberately short because the older doctypes with long DTD URLs were copied wrong so often.

Four earn a place on every page: charset (utf-8) so text decodes correctly, viewport so mobile browsers don't render a zoomed-out desktop layout, description which search engines often use as the result snippet, and Open Graph tags which control how links unfurl on social platforms and in chat apps.

The keywords meta tag is the trick half of this question: search engines have ignored it for years, and listing it as useful dates your knowledge badly.

Data attributes (data-*) store custom values on any element in valid HTML: data-product-id="42", data-state="open". JavaScript reads them through element.dataset, and CSS can select on them with attribute selectors, which makes them the standard bridge for passing small pieces of state between markup, style, and behavior.

Use them for element-scoped state and configuration. Don't use them as a database: anything sensitive or large belongs in JavaScript state, and anything with a real attribute (like disabled) should use the real attribute.

alt provides a text alternative for an image: screen readers announce it, browsers show it when the image fails to load, and search engines index it. Good alt text describes the image's function in context, briefly: 'Bar chart showing signups doubling in Q3', not 'chart' or 'image123'.

The senior detail: decorative images should carry an empty alt (alt=""), which tells screen readers to skip them entirely. Omitting the attribute is worse, because many readers then announce the file name.

Two ways: give the input an id and point the label's for attribute at it, or wrap the input inside the label element. Either way, screen readers announce the label when the input receives focus, and clicking the label focuses the field or toggles the control.

The click behavior matters more than people expect: it turns a 16-pixel checkbox into a full-sentence tap target on mobile. Placeholder text is not a label; it disappears the moment the user types and usually fails contrast requirements.

required blocks empty submission, type (email, url, number) validates format, min, max, and step bound numeric input, minlength and maxlength bound text length, and pattern matches a regex. When any of them fail, the browser blocks submission and shows a native message, with zero JavaScript written.

The judgment half of the answer: built-in validation is a UX layer, not a security layer. Anyone can bypass it in dev tools, so the server must validate everything again.

GET appends form data to the URL as a query string; POST sends it in the request body. GET requests are bookmarkable, shareable, and cacheable, which suits reads like search. POST suits writes: creating, updating, anything with side effects or data that shouldn't appear in the URL.

URLs leak: they land in browser history, server logs, and analytics tools. That's why passwords and personal data must never travel by GET, and why the method choice is a security decision, not a style preference.

An id identifies exactly one element per page, and each element carries at most one; classes group any number of elements, and each element can carry several. In CSS, #id outranks .class on specificity; in HTML, ids also serve anchor targets, label wiring, and ARIA relationships.

Most teams style with classes only. High id specificity makes overrides painful later, so ids get reserved for the jobs that genuinely need a unique reference: fragment links, for attributes, aria-labelledby.

One h1 describing the page, then h2 for major sections, h3 nested inside those, without skipping levels on the way down. Headings build the document outline that screen reader users jump between to scan a page, the same way sighted users skim the visual hierarchy.

Never pick a heading level for its font size; that's what CSS is for. A jump from h2 to h4 reads like missing content to assistive technology and to anyone auditing the page.

Every element renders as a rectangle built from four layers: the content area, padding inside the border, the border itself, and margin outside pushing neighbors away. Widths, backgrounds, and click targets all depend on which layer you're measuring, which is why this model opens most CSS interviews.

By default, width sets only the content area, so padding and border grow the visible box beyond the number you declared. That surprise is the setup for the box-sizing question that almost always follows.

border-box makes width and height include padding and border, so a 300px card measures 300px on screen no matter how much internal padding it carries. The default, content-box, adds padding and border on top of the declared width, which makes every layout calculation harder than it should be.

Nearly every codebase applies it globally in a reset. Percentage grids are the clearest win: three 33.33% columns with padding overflow their row under content-box and fit exactly under border-box.

Padding creates space inside the element, between its content and its border: it extends the clickable area and shows the element's own background. Margin creates space outside, between the element and its neighbors: it's always transparent and it can be negative. The choice is about who owns the space.

Two behavioral differences decide the edge cases: padding grows the hit area of buttons and links, while vertical margins between blocks can collapse into each other. If a click should land there, pad it; if siblings need breathing room, margin it.

When multiple rules target the same element, specificity picks the winner. Selectors are compared in tiers: inline styles beat ids, ids beat any number of classes, and classes beat any number of element selectors. When two selectors tie exactly, source order decides and the later rule wins.

The comparison is positional, not additive: eleven classes never outrank one id. That's why a single #sidebar selector can haunt every override attempt in a stylesheet, and why teams keep selectors flat and class-based.

The cascade is the algorithm that picks one winning declaration when several set the same property on the same element. It weighs, in order: origin and importance (user agent, user, author, !important), then specificity, then source order, with later rules beating earlier ones when everything else ties.

That ordering explains everyday behavior: why your rule loses to a more specific one no matter where you place it, and why swapping two equally specific rules changes the page. Modern @layer inserts an explicit layering step before specificity is even consulted.

px is a fixed length that ignores context. em scales with the current element's font size, so it compounds through nesting. rem scales with the root font size, one predictable reference for the whole page. vh and vw are percentages of the viewport's height and width respectively.

The convention most teams land on: rem for font sizes and spacing so user font settings scale the whole design, em for things tied to local text like icon sizing, px for hairline borders, and viewport units for full-screen sections.

The working set: block and inline for normal document flow, inline-block for inline placement with box control, none to remove an element from layout entirely, and flex and grid to turn a container into a flexbox or grid formatting context for its children.

Two details worth volunteering: display: none also removes the element from the accessibility tree, and flow-root creates a new block formatting context, the modern fix for containing floats and stopping margin collapse.

display: none removes the element from layout: it takes no space and screen readers skip it. visibility: hidden hides the element but keeps its box, leaving a gap where it stood. opacity: 0 makes it fully transparent while it keeps its space and, dangerously, still receives clicks.

The invisible-but-clickable behavior of opacity: 0 is a real bug class and an accessibility trap. If a hidden control shouldn't be reachable, use none or hidden; opacity is for animating things in and out.

static is the default flow. relative nudges an element from its normal spot and, more usefully, anchors absolutely positioned children. absolute removes the element from flow and positions it against the nearest positioned ancestor. fixed pins to the viewport. sticky scrolls normally until it hits an offset, then pins.

Use cases map cleanly: relative for anchoring, absolute for badges and dropdowns, fixed for the persistent chat bubble, sticky for table headers. The perennial bug is an absolute element positioning against the page because nobody set position: relative on the intended parent.

A pseudo-class selects an element in a particular state or position: :hover, :focus, :nth-child(2n), :not(.active). A pseudo-element styles a part of an element or generates content that doesn't exist in the markup: ::before, ::after, ::first-line, ::placeholder. State versus part, in four words.

The syntax rule: single colon for pseudo-classes, double colon for pseudo-elements, though browsers still accept :before for legacy reasons. ::before and ::after render nothing without a content property, the first thing to check when one refuses to appear.

Combinators describe the relationship between two selectors: a space matches any descendant, > matches direct children only, + matches the immediately following sibling, and ~ matches all later siblings at the same level. They let you target structure, like the first paragraph after a heading, without adding classes everywhere.

The descendant space deserves caution in large codebases: .sidebar a reaches every link at any depth, including ones inside components you didn't mean to touch. Child and sibling combinators keep the blast radius small.

Three ways: inline styles in a style attribute, internal CSS in a style block in the head, and external stylesheets linked with a link tag. External wins for real projects: one cached file styles every page, keeps markup clean, and gives the team a single place to work.

Inline styles carry the highest specificity, so they're painful to override and usually a code smell, except in HTML emails (where clients strip stylesheets) and for values computed by JavaScript. Internal blocks earn their place as inlined critical CSS for performance.

The modern answer is flexbox on the parent: display: flex with justify-content: center and align-items: center. Grid is even shorter with place-items: center. For horizontal centering alone, a block element with a set width takes margin-inline: auto. Absolute positioning plus a transform handles out-of-flow overlays.

Interviewers ask for multiple methods to see whether you know why each exists: flex and grid for general layout, auto margins when there's no flex parent to touch, and the transform trick when the element is out of flow, like a modal.

When two vertical margins meet, they merge into a single margin equal to the larger of the two rather than adding up. It happens between adjacent siblings, between a parent and its first or last child, and on empty blocks. Horizontal margins never collapse, and flex and grid items are immune.

The surprising case is parent-child: a child's margin-top can escape through the parent and move the parent itself down. Padding, a border, or a new formatting context on the parent (display: flow-root) stops the escape.

display: flex lays a container's children out along a main axis, set by flex-direction (row by default), with the cross axis running perpendicular to it. justify-content distributes items along the main axis, align-items aligns them along the cross axis, and gap spaces them without margin hacks.

Everything in flexbox is defined against those two axes, never against left, right, top, or bottom. That's the concept this question checks: switch flex-direction to column, and justify-content suddenly controls vertical distribution.

flex-basis sets an item's starting size along the main axis. flex-grow distributes leftover space proportionally when the container has room: an item with grow 2 gains twice what a grow-1 sibling gains. flex-shrink distributes the deficit the same way when the items would overflow the container.

The shorthand flex: 1 expands to 1 1 0%, meaning ignore the content's natural size and share all space equally, which makes it the standard 'equal columns' one-liner. flex: none locks an item at its basis.

justify-content distributes items along the main axis. align-items aligns items within their line on the cross axis. align-content distributes the lines themselves when a wrapped flex container has multiple rows and spare cross-axis space; on a single-line container it does nothing at all.

That single-line detail is the differentiator: candidates who've fought a real wrapping bug know align-content only activates with flex-wrap: wrap and room to spare. Grid reuses the same names, with the justify-* properties controlling the inline axis.

display: grid turns a container into a two-dimensional layout: you define columns and rows with grid-template-columns and grid-template-rows, and children fill the cells automatically or place themselves with line numbers or named areas. gap handles spacing, and the fr unit shares leftover space proportionally.

Grid's break from every earlier technique is that the layout lives on the container, not the items. The parent declares the structure once and items slot in, which is why page-level scaffolding is grid's home ground.

grid-template-areas lets you name regions of a grid and draw the layout as text right in the CSS: each quoted string is a row, each word is a cell, and repeating a name spans that region across cells. Items then claim a region with grid-area: name.

Two payoffs: the stylesheet becomes a readable picture of the page, and responsive changes become a redraw, rearranging the entire layout inside one media query without touching any item's rules. A dot marks a deliberately empty cell.

Both generate as many columns as fit, using repeat() with a minmax() track size. auto-fill keeps the empty tracks when there are fewer items than columns, so items sit at their minimum-based width. auto-fit collapses the empty tracks, letting the actual items stretch across the freed space.

The difference shows with few items in a wide container: auto-fit stretches two cards across the full row, auto-fill leaves them small beside ghost columns of empty space. Either way, this one line is the standard no-media-query responsive card grid.

Flexbox lays out along one axis at a time and lets content size drive the result, which suits toolbars, navs, and rows of tags. Grid controls two dimensions from the container, which suits page shells, dashboards, and any design where rows and columns must stay aligned with each other.

They compose rather than compete: a grid usually frames the page while flexbox arranges the innards of each cell. 'Content drives flexbox, the container drives grid' captures the design difference, not just the syntax difference.

Media queries apply CSS conditionally based on viewport width, orientation, resolution, or user preferences like dark mode and reduced motion. Mobile-first means writing base styles for small screens and layering min-width queries on top as space grows, instead of desktop styles with max-width overrides undoing them.

Mobile-first tends to produce less code because small-screen layouts are naturally simple: stack everything. Each breakpoint then adds columns and chrome. The desktop-first inverse spends its queries switching complexity off, which is where override bugs breed.

srcset lists the same image at multiple widths and lets the browser pick the best file for the current viewport and pixel density, guided by a sizes attribute that describes the image's layout width. The picture element goes further, switching sources by media condition or file format.

The division of labor: srcset for resolution switching (same picture, different file sizes), picture for art direction (a tight square crop on mobile, a wide shot on desktop) and for format fallbacks like AVIF down to JPEG.

Without it, mobile browsers assume the page was built for desktop, render it on a virtual canvas around 980px wide, and zoom out until it fits, producing tiny unreadable text. width=device-width with initial-scale=1 matches the layout viewport to the device so responsive CSS actually engages.

It's the single line that makes everything else in responsive design work: media queries written for 375px never fire while the browser pretends to be 980px wide. Avoid user-scalable=no; blocking pinch zoom is an accessibility failure.

z-index only applies to positioned elements (plus flex and grid children), and it only competes within the element's own stacking context. A stacking context is a sealed layering group created by things like a positioned element with z-index, opacity below 1, or any transform. Children can't escape it.

That's the bug behind 'z-index: 999999 does nothing': the element is trapped inside a context whose root sits below the competitor. The fix is raising the context root or removing the property that created the context, never a bigger number.

A transition interpolates a property between two states when something triggers the change, like a hover or a class toggle: it needs a trigger and has an implicit start and end. An animation runs on its own timeline with @keyframes, any number of steps, looping, and direction control.

Choose by autonomy: feedback tied to an interaction is a transition; anything that plays by itself, loaders, pulsing indicators, multi-stage sequences, is an animation. Both should stick to transform and opacity when smoothness matters.

transform moves, rotates, scales, or skews an element visually without changing its place in layout: translate(), rotate(), scale(), and skew(), composable in a single declaration. Neighbors don't move, because layout still sees the original box; only the rendered pixels change position.

That layout independence is why transforms animate smoothly: the browser can composite them on the GPU without recalculating layout. It's also why translate(-50%, -50%) can center an element by its own dimensions, something top and left percentages can't do because they resolve against the parent.

Custom properties (--accent: #0a7f5b) are values you define once, usually on :root, and read anywhere with var(). Unlike Sass variables, they live in the browser at runtime: they cascade, inherit, respond to media queries and class changes, and JavaScript can read and update them live.

That runtime nature is the whole answer to 'why not Sass variables?': theming by swapping a class on body, dark mode via a media query, and per-component overrides all work without recompiling anything.

BEM (Block, Element, Modifier) is a naming convention: .card for the component, .card__title for a part of it, .card--featured for a variant. Every selector is one flat class, so specificity stays uniform across the codebase and styles can't leak between components by accident.

The underlying problem is that CSS is global: any selector can hit any element, and specificity wars escalate. BEM solves it by convention; CSS Modules and utility frameworks solve the same problem with tooling. Recognizing it's one problem with several answers is the senior part.

Some properties pass from parent to child automatically: mostly text properties like color, font-family, line-height, and text-align. Box properties like margin, padding, border, and width don't inherit, because layouts would collapse into chaos if they did. Inherited values rank below any author rule in the cascade.

You can steer it manually: inherit forces inheritance, initial resets to the spec default, unset picks whichever of those is natural for the property, and revert falls back to the browser stylesheet. Setting font-family once on body works entirely because of inheritance.

!important lifts a declaration above all normal declarations in the cascade, regardless of specificity. When two !important rules clash, specificity decides between them. It's a blunt instrument: once one override goes important, the next override has to as well, and the stylesheet starts an arms race.

The legitimate uses are narrow: utility classes that must always win, overriding third-party styles you can't edit, and user stylesheets for accessibility, where the cascade deliberately gives the user's !important the final word.

ARIA adds accessibility semantics HTML can't express: aria-expanded on a disclosure button, aria-label for an icon-only control, role="alert" for live announcements. The first rule of ARIA is to prefer native HTML: a real button ships keyboard support and semantics that role="button" on a div never will.

ARIA changes what assistive technology announces, never how elements behave: a role provides no keyboard handling, focus management, or default behavior. Wrong ARIA is worse than none, because it makes confident promises the widget doesn't keep.

A sticky footer sits at the bottom of the viewport on short pages and gets pushed down naturally by long content. The modern solution is a full-height flex column: the page wrapper takes min-height: 100vh, and the main content takes flex: 1 to absorb whatever space is left.

Grid does the same with grid-template-rows: auto 1fr auto for header, content, and footer. Both beat the older negative-margin hacks because they need no magic numbers and survive content changes without breaking.

Single-line truncation takes three declarations working together: overflow: hidden to clip the text, white-space: nowrap to stop it wrapping, and text-overflow: ellipsis to draw the dots. All three are required; text-overflow alone does nothing, which is why this classic snippet gets fumbled in interviews.

Multi-line truncation uses line-clamp (long written as -webkit-line-clamp with box-orient), now widely supported. Add the caveat: clipped text should stay reachable somewhere, a title attribute or an expandable state, or you've hidden content with no path back to it.

It's the sequence between receiving HTML and painting pixels: parse HTML into the DOM, parse CSS into the CSSOM, combine them into the render tree, run layout to compute geometry, then paint and composite. Anything that stalls an early stage delays the user's first view of the page.

The two classic stalls: CSS is render-blocking, because the browser refuses to paint until styles are known, and synchronous scripts block HTML parsing because they might document.write. Optimizing means shrinking or deferring whatever sits on that path.

Browsers won't paint until all applicable stylesheets have loaded and parsed, because painting first and restyling after would flash unstyled content and thrash layout. Every stylesheet linked in the head therefore delays first paint by at least its own download and parse time, on every page load.

The mitigations: inline the critical above-the-fold CSS directly in the head, split the rest per route, mark print styles with media="print" so they stop blocking, and preload fonts the CSS will request. Shipping less CSS beats clever loading every time.

A plain script pauses HTML parsing while it downloads and executes. async downloads in parallel and executes the moment it arrives, in whatever order the network delivers. defer downloads in parallel but waits to execute until parsing finishes, preserving the order scripts appear in the document.

The practical mapping: defer for application code that touches the DOM, async for independent scripts like analytics that don't care about order, and end-of-body blocking scripts only in legacy codebases. Modules (type="module") defer by default.

Reflow (layout) recomputes element geometry; repaint redraws pixels. Changing width or top triggers layout for the element and often much of the tree, then paint, then composite. Changing transform or opacity can skip both stages: the compositor moves or fades an already-painted layer on the GPU.

That's the rule behind smooth animation: animate transform and opacity, avoid animating layout properties like height and margin, and batch DOM reads and writes in JavaScript so interleaved access doesn't force synchronous layout, the pattern known as layout thrashing.

Browsers match selectors right to left: for .nav a, the engine starts from every anchor on the page and walks up looking for an ancestor with .nav, not the other way around. The rightmost part, the key selector, decides how many elements become candidates in the first place.

The honest performance answer: on modern engines, selector matching rarely shows up in profiles, and readability should win. It gets real with universal selectors or deep descendant chains across huge DOMs, but the right-to-left model is what interviews actually check.

@layer lets you declare named layers in priority order (reset, vendor, components, utilities) and assign rules to them; the cascade compares layer order before specificity. A rule in a later layer beats any specificity in an earlier one, so utilities can override components with single-class selectors.

It's the language-level fix for specificity wars: import a heavy third-party stylesheet into an early layer and your later-layer styles win calmly, with no !important and no selector inflation. Unlayered styles beat all layered ones, the ordering detail most people miss.

Container queries style an element based on the size of an ancestor container rather than the viewport: mark the ancestor with container-type: inline-size, then write @container rules against its width. The same card component can render as one column in a sidebar and three in the main area.

That's the difference in one sentence: media queries respond to the page's context, container queries to the component's. They make genuinely reusable responsive components possible, which is why design systems adopted them quickly once cross-browser support landed.

Pick one scoping strategy and enforce it: a naming convention like BEM, build-time scoping like CSS Modules, utility-first like Tailwind, or cascade layers separating reset, vendor, components, and utilities. Keep specificity flat and boring, put design tokens in custom properties, and remove dead rules in the build.

the question needs trade-off literacy, not brand loyalty: conventions depend on team discipline, tooling buys guarantees at build complexity, utilities trade markup verbosity for zero naming and zero dead CSS. The you used, what hurt, and what you'd pick again.

Holy grail is the classic page: header, footer, and a middle band of nav, main content, and aside, with the middle stretching to fill the viewport. Grid solves it in a few lines: template areas draw the regions, grid-template-rows: auto 1fr auto makes the middle absorb spare height.

The senior half is history and responsiveness: this layout took nested floats and negative margins for a decade, and the grid version collapses to a single column on mobile by redrawing grid-template-areas inside one media query.

clamp(min, preferred, max) locks a value between two bounds while the middle expression scales freely: font-size: clamp(1.75rem, 1.2rem + 2.5vw, 3.5rem) grows smoothly with the viewport and never leaves the readable range. One declaration replaces a whole stack of breakpoint font-size overrides.

The accessibility caveat that marks production-ready answers: a pure-vw middle term ignores browser zoom and user font settings, so always mix a rem component into the preferred value, as above, to keep text scalable.

Fonts block text rendering while they download: browsers either hide text (FOIT) or show a fallback and swap (FOUT). font-display: swap chooses the swap behavior explicitly, preload fetches the file early, and self-hosting woff2 with subsetting cuts the payload itself rather than juggling it.

The remaining problem is layout shift at swap time; size-adjust and metric-matched fallback fonts shrink it. And the cheapest fix of all is fewer weights: every variant is another file on the critical path.

Four levers: modern formats (AVIF, WebP) with picture fallbacks, responsive files via srcset so phones don't download desktop pixels, loading="lazy" for below-the-fold images, and width and height attributes (or aspect-ratio) so the browser reserves space before a single byte of image arrives.

The layout-shift half is the differentiator: dimension attributes let the browser compute the box up front, which is most of fixing CLS. And never lazy-load the hero image; that delays the largest contentful paint instead of helping it.

Never remove outlines without a replacement: keyboard users move through the page by focus, and outline: none with nothing else makes it unusable to them. :focus-visible applies focus rings only for keyboard-driven focus, resolving the old fight between designers hating mouse-click rings and accessibility requiring them.

Beyond styling, focus must be managed: opening a modal moves focus into it and traps tabbing, closing returns focus to the trigger, and custom widgets need tabindex and key handling that native elements would have provided free.

It's a media feature reflecting an OS-level setting for users whom motion makes ill: for people with vestibular disorders, large animated movement is physically nauseating. Sites check @media (prefers-reduced-motion: reduce) and tone animation down to opacity changes or nothing, while keeping every feature working.

The pragmatic pattern is a global override that shortens all animation to near-zero for those users, plus intent where it matters: reduce means reduce, not necessarily eliminate; a subtle fade is usually fine where a parallax fly-in isn't.

Shadow DOM gives an element its own encapsulated DOM subtree with scoped styles: outside CSS doesn't reach in, inside styles don't leak out. It's the browser-native isolation behind web components and built-in widgets like video controls, the same idea CSS Modules approximate at build time.

Crossing the boundary is deliberate: custom properties inherit through it (the standard theming API), ::part exposes named internals for outside styling, and :host styles the component from within. Knowing those three doors is the practical layer of this answer.

Reproduce and isolate first: confirm the exact browser and version, then cut the page down to a minimal case, deleting CSS until the bug disappears and the guilty declaration is obvious. Comparing computed styles in both browsers' dev tools usually names the property that resolves differently.

Then check support data (MDN, caniuse) and known bug trackers before writing a workaround, prefer a fix that's harmless everywhere over browser sniffing, and keep the reduced case in your notes or tests. The method is the answer; the specific bug barely matters.