Can I publish client work without asking permission if I remove personal data?

No. Redacting personal data reduces privacy risk but does not override confidentiality clauses in your contract. Always check your agreement and ask the client directly before publishing.

What is the difference between a screenshot and a mockup for portfolio purposes?

A screenshot captures a built, functioning interface. A mockup is a static design file that has not been coded or used in production. Label each one accurately — misrepresenting a mockup as a live product misleads potential clients.

What should I do if a client refuses permission to show their project?

Respect the decision. You can describe the project type and your role in text without visuals, or use it as an internal case study for pitches under NDA. One restricted project will not significantly harm a portfolio.

How many screenshots should I include per project?

Two to four is usually enough: one wide context shot and one or two detail shots showing the specific problem you solved. More than that risks diluting the story rather than strengthening it.

Do I need to keep original screenshots after a project ends?

Yes. Originals are useful for future client handovers, design audits, or updating your portfolio later. Store them in a clearly named folder alongside any permissions correspondence.

Preparing Project Screenshots for a Small Portfolio Website

Your portfolio only works if visitors can quickly understand what you made and why it mattered. That starts well before you open a design tool — it starts with choosing the right screenshots and preparing them honestly.

Choose Screenshots That Explain Your Contribution

Pick images that show a clear before/after, a key interaction, or a distinctive design decision — not just a homepage hero because it looks nice. Ask yourself: if someone spent five seconds on this image, would they understand what the project was and what you specifically did?

Prefer shots that show the part of the interface you designed or built, not stock sections the client swapped in later.
Include one 'wide' context shot (the full page or dashboard) and one or two detail shots (a component, a form, a data visualisation).
If a project was mostly back-end or invisible logic, screenshot the admin panel, a meaningful report, or a before/after workflow comparison instead.
Avoid decorative shots that look good but reveal nothing about the problem you solved.

Remove Visible Private Information

Before any screenshot is published, scan it carefully for personal data: real names, email addresses, phone numbers, financial figures, order IDs, internal URLs, or anything that identifies an end user. Blur, crop, or replace these areas with clearly fictional placeholder values (e.g. 'Jane Sample', '£0.00', 'example@email.com').

Important: removing visible data reduces risk but does not automatically make publication permissible. Data protection obligations and confidentiality clauses exist independently of what appears on screen. Redaction is a hygiene step, not a legal clearance.

Check Permission to Publish

Review your contract or SOW before putting any client work online. Many agreements include a confidentiality clause, a sign-off requirement, or a restricted portfolio clause. When in doubt, email the client a short, direct question: 'Are you happy for me to include screenshots of [project] in my portfolio?' Keep their reply.

Some clients will approve screenshots but ask you to withhold the company name — that is a reasonable compromise.
For speculative or unpublished work, note clearly that the project did not go live.
If a client says no, respect it. One declined request will not ruin your portfolio; one legal dispute will.

Distinguish Real Screenshots from Concept Mockups

A screenshot is a capture of a live or fully built interface. A mockup is a static design file — it may look identical on screen but has not been coded, tested, or used by real people. This distinction matters because potential clients make decisions based on what they believe you have actually shipped.

Label each piece clearly. A caption that says 'Concept mockup, not implemented' is honest and still demonstrates your design thinking. Passing a Figma frame off as a live product is misleading, even if unintentional. If something is a concept, say so — it will not hurt you, and it builds trust.

Write Useful Captions

Captions do heavy lifting for both human visitors and search engines. A good caption names the project type, your role, and the one thing the image is showing — in plain English, in two sentences or fewer.

Weak: 'Dashboard screenshot.'
Strong: 'Analytics dashboard built for a logistics client. I designed the data hierarchy and built the front-end filters in React.'
Include the tool or technology if it is genuinely relevant to your audience.
Avoid vague superlatives like 'beautiful' or 'stunning' — describe what the work does.

Keep Your Originals

Always store the full-resolution, unedited screenshots alongside any edited or cropped versions you publish. Organise them by project in a clearly named folder structure. When you hand a project over to a client or a new agency, they may ask for original assets, and a well-organised archive saves time and demonstrates professionalism.

A simple naming convention works well: ClientName_ProjectType_ScreenName_v1.png. Add a brief README text file inside each project folder noting the date, the tools used, and any permissions already obtained.

A Quick Pre-Publish Checklist

Does this screenshot show my actual contribution?
Have I removed all visible personal or confidential data?
Do I have written or explicit verbal permission to publish?
Is the image correctly labelled as a screenshot or a concept mockup?
Does the caption explain the project, my role, and what the image shows?
Have I saved the original in a project folder with a logical name?