Build a Simple Portfolio Website with HTML and CSS

You can build a simple portfolio website with HTML and CSS by defining three to five sections (hero, about, projects, skills, contact), writing semantic markup, applying a readable layout with CSS, and deploying the static files to any static host. You do not need a JavaScript framework for a strong first portfolio. Clarity and proof of projects matter more than animations.

This tutorial walks through a realistic beginner build. Examples are illustrative and inspected for HTML/CSS correctness; they were not deployed from this drafting environment.

Plan the content before the pixels

Write a one-page outline:

1. Hero — your name, one-line role, primary CTA (projects or contact).
2. About — 3–5 sentences on what you are learning and what you want next.
3. Projects — two projects with problem, stack, and link/README.
4. Skills — honest list grouped by confidence.
5. Contact — email and optional professional profile links.

Gather real project URLs first. A beautiful empty portfolio helps less than a plain page with working links.

Semantic HTML skeleton

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">
  <title>Your Name — Portfolio</title>
  <link rel="stylesheet" href="styles.css">
</head>
<body>
  <header>
    <p class="brand">Your Name</p>
    <nav aria-label="Primary">
      <a href="#projects">Projects</a>
      <a href="#skills">Skills</a>
      <a href="#contact">Contact</a>
    </nav>
  </header>
  <main>
    <section id="about">...</section>
    <section id="projects">...</section>
    <section id="skills">...</section>
    <section id="contact">...</section>
  </main>
  <footer><p>© Your Name</p></footer>
</body>
</html>

Use landmarks (header, main, nav, footer) and meaningful headings. Screen readers and future you both benefit.

CSS layout that stays maintainable

Start with CSS variables for colour and spacing, a simple max-width container, and a responsive grid for project cards:

:root {
  --bg: #f6f7fb;
  --ink: #1c2434;
  --accent: #0f766e;
  --max: 960px;
}
body {
  margin: 0;
  font-family: Georgia, "Times New Roman", serif;
  color: var(--ink);
  background: var(--bg);
  line-height: 1.6;
}
.container { width: min(100% - 2rem, var(--max)); margin-inline: auto; }
.projects {
  display: grid;
  gap: 1rem;
  grid-template-columns: repeat(auto-fit, minmax(240px, 1fr));
}
a { color: var(--accent); }

Prefer relative units and flexible grids over fixed pixel mazes. Test at a narrow phone width early.

Make the page responsive from the start

Do not treat mobile layout as a final repair. Build the narrow version first, then add a media query only when the content has enough room for a wider arrangement. Navigation links should wrap without overlapping, cards should never force horizontal scrolling, and project screenshots should use max-width: 100% so they remain inside their containers. Test at several widths rather than targeting one phone model.

Also check the page with browser zoom at 200 percent. Text and controls should remain usable without content disappearing. Use padding to create breathing room, but avoid fixed heights on sections containing text because headings or descriptions may wrap differently across devices. Responsive design is not simply making everything smaller; it preserves reading order, touch targets, and visual hierarchy as available space changes.

Project cards that prove skill

Each card should answer: What problem? What did you build? Where is the code or demo?

• Title linked to repository or live demo.
• Two bullet outcomes (“implemented form validation”, “documented setup”).
• Tech tags that match the README.

If a project is unfinished, label it “in progress” rather than implying production polish.

Accessibility and polish checklist

• Colour contrast readable for text and links.
• Focus styles visible for keyboard users.
• Images include descriptive alt text (or empty alt if decorative).
• Skip redundant “click here” anchors; use descriptive link text.
• Validate HTML and check the page without CSS once to confirm order still makes sense.

Deploy the static site

Any static host works: GitHub Pages, Netlify, or similar. Typical flow:

1. Put index.html and styles.css in a repository.
2. Enable static hosting for the main branch.
3. Visit the URL on phone and desktop.
4. Add the URL to your résumé.

Custom domains are optional for a first version.

Common beginner mistakes

• Heavy animation libraries before content exists.
• Stock photos that look unrelated to your work.
• Broken project links.
• Copying a template so completely that nothing personal remains.
• Building only on a wide desktop monitor.

A practical one-weekend build order

If you have limited time, use this sequence rather than polishing endlessly:

1. Friday evening — write the about paragraph and project blurbs in a plain text file.
2. Saturday morning — convert the outline into semantic HTML; ignore styling beyond a basic stylesheet link.
3. Saturday afternoon — add CSS variables, container width, and the projects grid; check a phone-sized viewport.
4. Sunday — fix broken links, add alt text, deploy to a static host, and share the URL with one friend for feedback.

Stopping criteria matter. When the page loads, the contact method works, and two projects have honest descriptions, you have a shippable v1. Everything else is iteration.

Content writing tips that improve the design

Portfolio CSS cannot rescue vague writing. Tighten copy with these rules:

• Replace adjectives (“passionate coder”) with evidence (“built X that does Y”).
• Keep the about section under 120 words.
• Use the same project names on GitHub, résumé, and the site.
• Date projects roughly (“2025”, “2026”) so visitors know what is recent.

Design follows content: once text is honest, choose spacing and type sizes that make scanning easy. A single accent colour and consistent card padding usually look more professional than five competing decorations.

Optional enhancements after v1 ships

Only after the first deploy: add a print stylesheet, Open Graph tags for link previews, a simple favicon, and compressed images. Measure loading on a mid-range phone network. Resist turning the portfolio into a full CMS. Static HTML remains easy to update during exam season and internship applications.

If you later learn UI/UX concepts, revisit visual hierarchy — but do not delay shipping while waiting for perfect taste. Iteration on a live URL teaches faster than endless local tweaks.

When to add JavaScript later

Add JS for a theme toggle, form enhancement, or filtering projects — after the HTML/CSS story is solid. Frameworks come after you can explain your markup. If you want structured coaching on layout and responsive design, explore SKLI’s Web Designing training course and related options in the courses index.

Next steps and support

Ship a minimal version in one weekend, then iterate weekly. For programme questions, see the SKLI home page or contact SKLI. Pair the portfolio with internship-ready habits described in career guides — but keep this page focused on demonstrating craft.

FAQ

A simple HTML and CSS portfolio is a communication tool: semantic structure, readable design, and honest project proof. Build the outline, ship the static files, fix mobile layout, and keep improving one section at a time.