What goes in an online portfolio and where to put it

An online portfolio is a website that displays your best work — code projects, designs, writing, or whatever you make — so that employers, clients, or collaborators can see what you actually do. It lives on its own domain (like yourname.com) or a subdomain (like portfolio.yourname.com), and you control what appears there.

The portfolio itself is usually built with HTML, CSS, and JavaScript — the same tools you use to build any website. You can write the code from scratch, use a static site generator like Hugo or Jekyll, or use a website builder like Webflow or Squarespace that handles the code for you. The choice depends on how much control you want and how much time you want to spend on the technical side versus the content side.

What you include matters more than how fancy the site is. Employers looking at a developer portfolio want to see actual projects with links to the live code or the running process. A designer's portfolio needs screenshots or embedded work samples. A writer's portfolio needs links to published pieces or a few strong examples. The portfolio should answer: what can this person do, and what did they actually build?

Key Takeaways

  • Your portfolio should live on a domain you own or control, with a clear URL that you can share on a resume or in an email.
  • Include 3 to 5 of your strongest projects with descriptions of what you built, what problem it solved, and what technologies you used.
  • Link to the live version of each project and to the source code (on GitHub, for example) so viewers can see both the result and how you built it.
  • Write a short bio that explains what you do and who you build for, rather than a generic summary of your skills.
  • Keep the design clean and fast — a slow or cluttered portfolio suggests you do not pay attention to user experience.

Choosing between building from scratch and using a builder

If you are a web developer, building your portfolio from scratch in HTML and CSS is itself a portfolio piece. It shows you understand how the web works and can write clean code. You control every detail, and the site will be as fast and lightweight as you make it. The downside is that it takes time, and you have to handle hosting and deployment yourself.

If you are not a developer, or if you want to launch quickly, a website builder like Webflow, Squarespace, or Wix handles the technical side. You pick a template, add your content, and the builder generates the HTML and CSS for you. These services also include hosting, so you do not have to set up a server. The trade-off is less control over the code and usually a monthly fee.

A middle ground is a static site generator like Hugo, Jekyll, or Eleventy. You write your content in plain text or Markdown, the generator turns it into HTML, and you push the result to a hosting service like Netlify or Vercel. This approach is faster than coding from scratch, gives you more control than a builder, and is often free or very cheap to host.

What to include in each project description

For each project, write a short paragraph (3 to 4 sentences) that covers: what the project is, what problem it solves, what you built, and what technologies you used. Do not just list the tech stack — explain why you chose it or what it let you do.

Example: "A task management app built with React and Firebase. Users can create projects, assign tasks to team members, and see real-time updates when anyone makes a change. I chose Firebase for the backend because it handles real-time synchronization without needing to build a custom server, and React because the component structure made it straightforward to manage the app state as the feature set grew."

Include a link to the live version (if it is still running) and a link to the GitHub repository or wherever the code lives. If the project is not live anymore, a screenshot plus the code link is enough. If you cannot share the code because it was proprietary work, describe what you built and what you learned, and link to a screenshot or a case study instead.

Hosting and domain options

You need two things: a domain name (yourname.com) and a place to put the files (a web host). You can buy the domain and hosting separately, or buy them together from a registrar like Namecheap or GoDaddy.

For hosting, the cheapest option for a static site (HTML, CSS, JavaScript with no server-side code) is a service like Netlify, Vercel, or GitHub Pages. These are free or very cheap, they handle SSL certificates so your site runs on HTTPS, and they deploy automatically when you push code to a repository. If you built your site with a static site generator, these services are designed for exactly that workflow.

If you used a website builder like Webflow or Squarespace, hosting is included in the monthly fee. If you built a site that needs a server (with Node.js, Python, or another backend language), you will need a service like Heroku, DigitalOcean, or AWS. These cost more but give you more power.

Making your portfolio findable and keeping it current

Your portfolio URL should be straightforward to remember and spell. Ideally it is your name (priya.com, priyadesai.com) or your name plus a descriptor (priyadesai-design.com). Avoid numbers, hyphens, or abbreviations unless your name is actually spelled that way. Put the URL on your resume, LinkedIn profile, and email signature so people know where to find it.

Update your portfolio every few months as you finish new projects. Remove old work that no longer represents your current skill level. If a project is outdated but you are proud of it, add a note explaining what you learned from it. A portfolio that has not changed in two years suggests you have not been working or learning.

Test your portfolio on a phone and a tablet, not just a desktop. Make sure the images load fast, the links work, and the text is readable on a small screen. Use your browser's developer tools (the same ones you use to build websites) to check the performance and catch any broken links or missing images.

Common mistakes to avoid

Do not fill your portfolio with every project you have ever made. Three to five strong projects are better than ten mediocre ones. Employers spend 30 seconds looking at a portfolio — make those seconds count by showing your best work first.

Do not use auto-playing music, blinking text, or heavy animations that slow down the page. A clean, fast site that loads in under 2 seconds says you understand performance and user experience. A slow, flashy site says the opposite.

Do not write generic descriptions like "I used HTML, CSS, and JavaScript." Explain what you built and why it matters. What problem does it solve? Who uses it? What would have been harder without the tools you chose?

Do not forget to include a way for people to contact you — an email address, a contact form, or a link to your LinkedIn. If someone sees your work and wants to hire you, make it straightforward for them to reach out.

Frequently Asked Questions

Should I use a custom domain or a free subdomain?

A custom domain (yourname.com) looks more professional and is easier to remember and share. A free subdomain (like yourname.github.io) works fine technically, but it signals that you have not invested in your own brand. A custom domain costs $10 to $15 per year and is worth it.

How many projects should I include?

Start with 3 to 5 of your strongest projects. As you build more work, you can add to the portfolio, but do not include everything. Quality matters more than quantity. If you have fewer than 3 finished projects, build one or two more before launching your portfolio.

Can I include projects I built while learning?

Yes, as long as they show real skill. A tutorial project is fine if you modified it, added features, or learned something specific from it. Be honest about what you built versus what you copied. Employers respect learning; they do not respect dishonesty.

What if I do not have a GitHub account yet?

Create one. GitHub is where most developers share code, and employers expect to see your repositories. Even if you do not have much code to share yet, having a GitHub profile with a few projects is better than having none. You can make a repository private if you do not want to share the code publicly.

How often should I update my portfolio?

Add new projects as you finish them, and review the whole portfolio every few months. Remove projects that no longer represent your current skill level. A portfolio that has not changed in a year suggests you have not been building anything new.