HTML and CSS Interview Questions for Freshers (2026): The Skills Everyone Claims and Few Can Explain

Updated August 2026

HTML and CSS are the two skills nearly every web-inclined fresher lists and the two that hold up worst under questioning, for a specific reason: most people learn them by copying something that worked rather than by understanding why it worked. That is a perfectly reasonable way to build things and a poor way to survive an interview, because the questions asked are almost never "what is the syntax" — they are "why is this element not centred", "why is your z-index being ignored", "why does this look right on your laptop and broken on a phone".

How much this matters depends on which role you are actually targeting, and it is worth being clear with yourself. In a mass-recruiter technical round, HTML and CSS usually get a handful of shallow questions and the weight sits on programming fundamentals. For a frontend, web-developer or UI internship role, the position reverses: markup and styling are often the screening round itself, frequently as a live task where someone watches you build a small layout and asks why you chose what you chose. Preparing for the first when you are interviewing for the second is a common and avoidable mistake.

The good news is that this is a small, finite body of knowledge with unusually high returns. The box model, specificity, the positioning values, flexbox versus grid, and how the browser turns your file into pixels will cover most of what you are asked. Semantic markup and basic accessibility — which take an afternoon — are currently the fastest way for a fresher to stand out, because most candidates have never thought about either. And every answer here is verifiable in your browser in seconds, which is exactly how you should learn them.

Frequently asked questions

What is semantic HTML, and why does it matter?

Semantic HTML means using elements that describe the meaning of the content rather than only its appearance — header, nav, main, article, section, aside, footer, and correct use of headings, lists and buttons. It matters for three reasons worth stating together: screen readers use structure to let users navigate, so a page built from generic containers is far harder to use with assistive technology; search engines read structure to understand the page; and the markup becomes readable to the next developer. The practical version of this answer is that a clickable element should be a button, not a div with a click handler, because a real button is focusable, keyboard-operable and announced correctly for free.

When do you use div, section and article?

A div carries no meaning and is the correct choice when you need a container purely for styling or layout. A section groups related content that forms a distinct part of the page and would sensibly have a heading. An article is content that makes sense independently and could stand alone or be syndicated — a blog post, a news item, a product card, a comment. The honest test to describe in an interview: if you cannot give it a heading that describes it, it is probably a div rather than a section, and using semantic elements decoratively is not better than using a div.

What happens when a browser loads a page?

The browser parses the HTML into the DOM and the CSS into the CSSOM, combines them into a render tree containing what will actually be displayed, calculates the geometry of each element in a layout step, and then paints the pixels, compositing layers where needed. The details worth knowing: CSS is render-blocking because nothing can be painted until it is parsed, and a synchronous script in the head blocks HTML parsing, which is why scripts are placed at the end of the body or given defer. Changes that alter geometry force a re-layout, which is more expensive than changes that only repaint — which is why animating transform and opacity is smoother than animating width or top.

Explain the box model, and what box-sizing: border-box does.

Every element is a box made of content, then padding, then border, then margin. By default, a width you set applies to the content box only, so padding and border are added on top — an element with width 200px and 20px of padding on each side occupies 240px, which is where most unexpected layout overflow comes from. Setting box-sizing: border-box makes the width include padding and border, so 200px means 200px on screen. This is why nearly every project starts with a rule applying border-box to everything, and being able to explain that rule rather than just having copied it is exactly the kind of thing the question is checking.

How is CSS specificity calculated?

Specificity is compared in order of strength: inline styles beat IDs, IDs beat classes, attribute selectors and pseudo-classes, which beat element selectors and pseudo-elements. The universal selector adds nothing. Two rules of equal specificity are resolved by source order — the later one wins — which is why the cascade matters as much as specificity. !important overrides all of it and is the thing to be honest about in an interview: it is a signal of a structural problem in your stylesheet, and the professional answer is that you reach for it only in a genuine emergency and then go back and fix the underlying selector, rather than that you never use it.

Inline, block and inline-block — what is the difference?

Block elements start on a new line and take the full available width, and respect all width, height, margin and padding values. Inline elements sit within the text flow, take only the width of their content, and ignore width and height while treating vertical margin and padding as not affecting the surrounding layout — which is the source of a great deal of confusion when someone tries to add vertical spacing to a span or an anchor. Inline-block combines the two: it sits in the flow like an inline element but accepts dimensions and vertical spacing like a block one.

Explain the position values: static, relative, absolute, fixed and sticky.

Static is the default, meaning the element sits in normal flow and top, left and z-index have no effect. Relative keeps the element in the flow but offsets its visual position from where it would have been — and, importantly, makes it a positioning context for absolutely positioned children. Absolute removes the element from the flow entirely and positions it relative to its nearest positioned ancestor, falling back to the initial containing block if there is none, which is the mistake behind most absolute positioning that goes wrong. Fixed positions relative to the viewport and does not scroll with the page. Sticky behaves as relative until a scroll threshold is crossed and then behaves as fixed within its container, which is how table headers and navigation bars stay visible.

Flexbox or Grid — how do you choose?

Flexbox is one-dimensional: it distributes space along a single axis, which makes it right for a row of navigation items, a toolbar, centring, or a card footer that pushes to the bottom. Grid is two-dimensional: it controls rows and columns together, which makes it right for page layouts and any arrangement where alignment across both axes matters. The practical answer interviewers want is that these are complementary rather than competing — a page skeleton in Grid, with Flexbox inside individual components — and that content-driven sizing tends toward Flexbox while layout-driven structure tends toward Grid.

How do you centre a div horizontally and vertically?

Give more than one method, because the follow-up is always about trade-offs. With Flexbox: display flex on the parent with justify-content and align-items both centre — the modern default, and it works without knowing the child dimensions. With Grid: display grid and place-items centre, which is the shortest. Horizontally only, for a block element with a set width: margin left and right auto. The absolute positioning approach — top and left at 50 percent with a translate of minus 50 percent on both axes — still matters when the element must be removed from the flow, such as a modal. Mention that the parent needs a defined height for vertical centring to mean anything, since that is the actual reason it fails for most people.

What are inheritance and the cascade?

Inheritance means certain properties pass from parent to child automatically — typography-related ones such as colour, font-family and line-height do; layout-related ones such as border, padding and background do not. The cascade is how the browser resolves multiple competing rules for the same element, considering origin and importance first, then specificity, then source order. The useful practical point is that inheritance is why setting font-family once on the body works, and why an unexpected colour on a nested element usually means something above it is passing a value down rather than a rule directly targeting it.

What is margin collapsing?

When two vertical margins meet, they combine into a single margin equal to the larger of the two rather than their sum — so a 30px bottom margin above a 20px top margin produces 30px of space, not 50px. It also happens between a parent and its first or last child, which is why a container sometimes appears to have a margin it was never given. It applies only to vertical margins in normal flow, and it does not occur inside flex or grid containers, which is one practical reason modern layouts feel more predictable. Being able to name it is a strong signal, because it is the classic bug that people work around for years without knowing its name.

How do you make a layout responsive?

Media queries applied mobile-first: write the base styles for the smallest screen, then use min-width queries to add complexity as space allows. Mobile-first with min-width is preferred because it degrades safely, keeps the base stylesheet simpler and matches how most users arrive. Beyond queries, the modern answer is that much responsiveness comes from the layout method itself — flexible grids, percentage and fractional units, max-width on containers, and images with max-width 100 percent. And the meta viewport tag must be present, or a mobile browser renders at a desktop width and scales down, which is why an otherwise correct responsive page looks tiny on a phone.

px, rem, em, percentages, vh and vw — when do you use each?

px is an absolute unit and predictable, but it does not respond to a user who has increased their browser font size, which is an accessibility problem for text. rem is relative to the root font size and is the sensible default for typography and spacing because it scales with user preference and stays predictable. em is relative to the current element font size, which makes it useful for spacing that should scale with its own component but can compound confusingly when nested. Percentages are relative to the parent dimension. vh and vw are relative to the viewport, useful for full-screen sections — with the known caveat that mobile browser chrome makes 100vh taller than the visible area, which is why full-height sections often overflow on phones.

Pseudo-class versus pseudo-element?

A pseudo-class selects an element in a particular state or position — hover, focus, disabled, checked, first-child, nth-child — and is written with one colon. A pseudo-element creates or targets a sub-part of an element that does not exist as a separate node, such as before, after, first-line or placeholder, and is conventionally written with two colons. The practical distinction to mention: before and after require a content property to render at all, even if it is an empty string, and content generated this way is not reliably available to assistive technology, so it should be decorative rather than meaningful.

display: none, visibility: hidden and opacity: 0 — what is the difference?

display: none removes the element from the layout entirely: it occupies no space and is not announced to screen readers. visibility: hidden hides it but keeps its space reserved in the layout, and it is also hidden from assistive technology. opacity: 0 makes it fully transparent while keeping both its space and its interactivity — it can still be clicked and focused, and it is still read by screen readers, which is a genuine accessibility bug when used to hide things. Choosing between them by what you want to happen to the space, and to keyboard and screen-reader users, is what the question is really about.

Why does z-index sometimes not work?

Because z-index only applies to positioned elements — anything still position static ignores it — and because it operates within stacking contexts rather than globally. A new stacking context is created by things like a positioned element with a z-index value, opacity below 1, transform, filter, or will-change. Once an element sits inside a stacking context, its z-index is only compared with siblings inside that same context, so a child with z-index 9999 can never rise above an element that outranks its entire parent context. That last point is the answer interviewers are hoping for, because it explains the bug that arbitrary large numbers never fix.

What accessibility basics would you apply to a page?

Meaningful alt text on images that convey information and empty alt on decorative ones; real buttons and links rather than clickable divs; every form input associated with a label; a logical heading order that does not skip levels; sufficient colour contrast, and never colour alone to convey meaning; visible focus indicators kept rather than removed; and keyboard operability for everything interactive. On ARIA, the correct thing to say is that the first rule of ARIA is not to use it when a native element would do — a button element is better than a div with role button — and that incorrect ARIA is worse than none. This is a small amount of knowledge that very few freshers have, which makes it disproportionately valuable in an interview.

How should a form be built?

Every input needs an associated label, either wrapping it or connected by the for attribute matching the input id, so that clicking the label focuses the field and screen readers announce it. Use the appropriate input type — email, tel, number, date — because mobile keyboards adapt to it and browsers provide validation for free. Use native validation attributes such as required and pattern as the first layer, group related controls with fieldset and legend, and keep error messages specific and adjacent to the field rather than dumped at the top. A useful thing to add: never rely on the placeholder as a label, because it disappears the moment someone starts typing.

A layout is broken and you do not know why. How do you debug it?

Describe a method rather than a guess, because that is what is being assessed. Open the browser developer tools and inspect the element, look at the computed styles rather than the authored ones to see what actually applied and what was overridden, and check the box model diagram for unexpected padding or margin. Toggle properties off one at a time to isolate the cause. Use the layout overlays to visualise flex and grid lines. If something is invisible, check whether it has zero height, is behind another element, or is outside the viewport. Interviewers ask this to find out whether you debug systematically or by changing values until something looks right, and saying that you check computed styles first is a strong signal.

Is it worth preparing HTML and CSS deeply for 2027-batch placements?

It depends on the role, and being clear about that is itself the right answer. If you are targeting mass recruiters, a solid working knowledge is enough — the technical round will weight programming fundamentals, and depth here will not be tested much. If you are targeting frontend, web-developer or UI roles and internships, this is frequently the screening round, often as a live build task, and depth pays directly. Either way the investment is small and it compounds: React and every other framework sit on top of these fundamentals, so a student who understands the box model, specificity and layout debugs framework problems that others can only work around.

Don't just read HTML & CSS questions — get asked them

Phiny's AI interviews you on exactly these topics, follows up on weak answers, and tells you what a stronger answer looks like. Text interviews are free and unlimited.

Start a free AI mock interview

How to prepare

Where these questions get asked