Web developer hiring splits between people who ship interfaces users measurably like and people who list frameworks. The difference on paper is bullets tied to Core Web Vitals, conversion, and accessibility: numbers every production site tracks and almost no resume mentions. A recruiter can find a hundred resumes that say "React, Next.js, TypeScript"; the one that says "raised Lighthouse performance from 61 to 98 on a storefront with 1.2M monthly visitors, lifting mobile conversion 11%" gets the phone screen, because it proves the frameworks produced outcomes someone paid for.
Your portfolio link matters more in this role than almost any other, but it supplements the resume, it never replaces it: portals parse the PDF, not your site. The example below keeps every credential in parseable text and treats the portfolio as evidence, not structure. That means the resume must stand alone through the first screen: skills as literal keywords, results as plain-text numbers, and the portfolio URL written out where a human can retype it if the hyperlink dies in parsing.
Know who reads a web developer resume and in what order. First an ATS (Greenhouse, Lever, Workday at bigger companies) parses it into fields and a recruiter searches those fields for the posting's stack, usually without deep technical knowledge, which is why exact framework names matter. Then a hiring manager or lead developer reads for engineering judgment: what you shipped, what moved, what trade-offs you understood. Finally, interviewers mine your bullets for questions, so every claim needs a story behind it. Three audiences, one page: keyword-precise for the recruiter, outcome-dense for the manager, defensible for the interview.
The structure that works: a headline with your title and core stack ("Web Developer | React / Next.js"); a two-to-three-line summary with years, domain, and your best measurable result; experience with 3-4 bullets per role tied to performance, conversion, accessibility, or velocity; a projects section for anything with real usage; skills grouped frontend versus backend and tooling; then education, one line, no apology if it is unrelated. Links to portfolio and GitHub go in the header in plain text. One page until you are several roles deep; nobody reads a junior's second page.
Write experience bullets around metrics production sites already track. Core Web Vitals (LCP, CLS, INP), Lighthouse scores, bundle size, conversion and A/B results, accessibility audit counts, build and setup times, pages migrated with SEO intact. Each bullet: what you changed, the mechanism in a parenthetical, and the number that moved. "Lifted mobile conversion 11% by cutting LCP from 4.1s to 1.8s (image pipeline, route prefetching, third-party script audit)" shows fluency in one line. Team-scale wins count too: starter themes that cut setup from days to hours, component systems marketing uses without tickets. The quantifying guide helps when your numbers need reconstructing.
List skills the way postings spell them, grouped so both parsers and people scan fast. Frontend: React, Next.js, TypeScript, Tailwind CSS, Core Web Vitals optimization, accessibility (WCAG 2.1 AA). Backend and tooling: Node.js, PostgreSQL, REST and GraphQL APIs, testing (Playwright, Vitest), CI (GitHub Actions), the CMS and hosting you actually use. A filter for "Next.js" will not match "React ecosystem", so write each name separately and literally. Keep the list honest: every skill is an interview topic, and a stack you cannot discuss is a trap you set for yourself. The skills section guide covers grouping and pruning.
Treat education and certifications as supporting cast, not the lead. Most web developer roles hire on shipped work; list your degree or bootcamp in one line without apology, unrelated majors included (plenty of working developers hold media, music, or biology degrees). Bootcamp grads should name the program and lean on projects above it. Certifications matter less here than in most tech tracks; a cloud cert or accessibility credential (like IAAP CPACC) can support a positioning claim, but no certificate substitutes for a live site with numbers. If you are self-taught, say nothing about it in the resume and let the projects section make the argument.
Format for the parser first, the reader second, and resist the urge to design it. Single column, standard headings, no tables, no columns, no icons for skills, PDF export. You can build anything fancier; the portal will punish you for proving it. Consistent date formats, links written out in plain text, and file name with your actual name. The portfolio is where design lives; the resume is where parsing lives. If you want the full reasoning on layout trade-offs, see the best resume format guide; the short version is that boring formats win screens.
The recurring web developer resume mistakes are all self-inflicted. First: framework soup, listing twenty technologies with no evidence any produced an outcome. Second: clever titles ("UI craftsman", "code artisan") that match zero recruiter searches. Third: burying the portfolio URL in a hyperlink that parsers drop. Fourth: demo projects with no usage presented as if they were products; one tool with 2,100 registered sites beats five to-do apps. Fifth: a designed, two-column resume that scrambles in the ATS. Sixth: no accessibility or performance evidence at all, when those two words are climbing every posting's requirements list.
Use the top third for a summary once you have shipped anything professionally: years, domain (e-commerce, marketing sites, SaaS), stack, and your single best number. New developers use a short objective naming stack, best project with a real metric, and the role targeted; see resume summary examples for both shapes. Either way, the words "web developer" or "frontend developer" belong in your headline verbatim, because that is the search string recruiters type, and the headline is the highest-weighted line the parser reads.
Tailoring for web roles means matching the posting's stack and vocabulary line by line. If they say Vue and you have it even secondarily, it moves up; if they emphasize accessibility, your WCAG bullet leads; if it is an e-commerce shop, conversion and Core Web Vitals go first; agency postings care about deadlines and client count, product companies care about iteration and testing. Mirror exact terms ("server-side rendering", "headless CMS", "design systems") when you genuinely have them. The tailoring guide shows the quick pass; for developers it is usually reordering bullets and swapping the summary's last clause.
The 2026 reality for web developers: AI coding assistants are table stakes, junior postings increasingly assume them, and the differentiation has moved up a level to judgment: performance budgets, accessibility compliance, SEO-safe migrations, and knowing what not to ship. Postings mention Core Web Vitals and WCAG more every year because regulators and search rankings both enforce them. The market is tighter for juniors than it was, which raises the value of one live project with real users and one number that moved. Employers are not hiring framework lists; they are hiring people whose sites hold up in production.
Use this page as a working kit: copy the structure, replace Tyler's metrics with your own from Lighthouse, analytics, and your repo history, pull phrasing from the bullet bank, and run the ATS tips as a checklist. The FAQ covers degrees, WordPress positioning, and project selection. Before you send a single application, run the finished PDF through the resume checker to confirm the parse: developers lose screens to broken parsing more often than to weak experience, and it is the one bug you can fix in five minutes.