Password Protected Portfolio Website Guide

Share the Work, Not the Secret

A password-protected portfolio website lets you show real work and not publish it to everyone. This is important when examples contain client names, private results, unreleased designs, internal documents or work that a contract covers.

A password is not permission. Before you create a private portfolio link, decide what you can share, what you must remove and who gets access.

This guide covers the practical parts:

• Getting permission to show client work
• Removing recoverable information from files
• Choosing a shared password or email-verified access
• Setting it up on Cloudflare Pages, Netlify, Vercel or a document-sharing tool
• Handling forwarding, expiry and updates
• Knowing when not to share at all

How a Password-Protected Portfolio Website Controls Access

A password-protected portfolio sits between a public portfolio and a formal data room (a secure online store of documents for a deal). Selected people can view your work, but it does not show up in search results or in casual browsing.

The access method decides the steps for the visitor and how easily the link spreads.

Access method	Best use	Main limitation
Public link	Published projects, press material and approved case studies	Anyone can open or redistribute it
Shared password	Small client groups that already know one another	The link and password can be forwarded together
Email verification (one-time code)	Recruiting, proposals and reviews where you need to know who opened it	Adds a short verification step for each visitor

A private portfolio can hold more than web pages. You can share PDFs, presentations, design exports, working demos or videos. Do not make visitors create an account only to look at the work.

Use the gate to prevent casual exposure, not to guarantee secrecy. A recipient can still take screenshots, download files that you allow, or describe what they saw. A password reduces accidental exposure, but it cannot replace an NDA, contractual permission or proper redaction.

Get Permission Before Sending a Private Portfolio Link

Read the contract. Look for confidentiality clauses, intellectual property terms, publicity rights, portfolio-use language and approval requirements. Ownership of the design file does not automatically give you the right to publish client information.

If the contract says nothing about this, get written permission. A short email is better than a vague conversation from six months ago. State what you will show, what you will remove, who will see it, and how you will control access.

Situation	Recommended decision	Reason
Written approval covers a redacted case study	Share through a protected link	The permitted material and audience are documented
Contract is silent and the project is not public	Ask before you share	Silence is not reliable consent
Work contains personal, medical, financial or account data	Do not share the original	The harm from exposure is too high
Project reveals trade secrets, security controls, source code or unreleased strategy	Create a fictional substitute or do not share	A password does not remove the confidentiality duty
Client refuses portfolio use	Respect the refusal	A private gate does not override the agreement

This follows the idea of data minimization in Article 5 of the GDPR. Data minimization means that you expose only the information needed for the stated purpose. It is sensible practice, even when the law does not apply to you.

Redact Work Before Adding It to a Confidential Portfolio

Redaction is the permanent removal of information from a file. A black rectangle over the information does not remove it. If you only cover text in a PDF, slide deck or design file, the text can stay searchable, selectable or visible after editing.

Work on a separate portfolio copy:

1. Define the point of the example. Name the skill, decision or result that the piece must prove. You can remove everything else.
2. Remove identifying details. Replace each detail that the permission does not cover. Such details are client names, logos, employee names, email addresses, account numbers, URLs and recognizable screenshots.
3. Reduce sensitive numbers. If exact revenue, conversion, budget or user data is confidential, use ranges, percentages or indexed values. Never invent a result.
4. Clean hidden material. Look at comments, revision history, speaker notes, hidden slides, document properties, filenames, embedded files, hyperlinks and image metadata.
5. Export a flattened copy (a copy with all layers merged into one). Use the redaction or sanitization feature of the application. Open the export. Search it for the removed terms. Try to copy text from the redacted areas.
6. Test the private link. Open it in a private window or while you are signed out. Make sure that the gate, previews, downloads and filenames work as expected.

Eight pages of a 30-page report can be enough to prove your contribution. If you share that excerpt, you expose 73% fewer pages than with the full report. That cut often protects more than any access setting.

Shared Password or Email-Verified Access?

A shared password suits approved groups that need quick access. It fits when you do not need to know exactly who opened the work. Email-verified access suits cases in which each visitor must prove control of an email address that you approved.

Question	Shared password	Email verification
Is entry fast?	Yes, with the password	Yes, after the visitor enters a one-time code
Can access be tied to a person?	Rarely. Everyone uses the same password	Usually. Each visitor verifies an address
What happens if the link is forwarded?	Anyone with both can enter	The new visitor needs an approved address
Is it suitable for a hiring process?	Acceptable for one trusted contact	Better for several reviewers
Is it suitable for a client team?	Good for a small known group	Better when you need per-person records

If you use a password, make it unique. Do not use a password that you use for email, banking or another client. Send it separately from the link. For example, send the link by email and the password by text or chat.

NIST’s current digital identity guidance requires at least 15 characters for passwords used as the only authentication factor. A shared portfolio gate is not an account login. But a long, unique passphrase is still a sound baseline.

Where to Host a Private Portfolio

Most static hosts can serve a portfolio folder. But their access controls are very different, and several need a paid plan.

Option	Shared password	Email verification	Notes
Cloudflare Pages with Cloudflare Access	No	Yes, with the One-time PIN login method	You list the approved email addresses in an Access policy
Netlify	Yes, on Pro plans and above	No (team login covers your own team members)	Password protection is not available on the Free and Personal plans
Vercel	Yes, as a paid option on Pro and included on Enterprise	No	Vercel Authentication limits access to Vercel users you grant access, or to holders of a shareable link
GitHub Pages	No	No	Private Pages sites need GitHub Enterprise Cloud and are visible only to people with read access to the repository
DocSend or Papermark	Yes	Yes, on some plans	Good for a PDF or deck portfolio. They also show who viewed which pages

For a portfolio website for named people only, Cloudflare Pages with Access is the closest match to email-verified access. If your plan includes it, Netlify or Vercel password protection is simpler for a small group that is happy with one password.

Set Up a Private Portfolio on Cloudflare Pages with Access

These steps follow Cloudflare’s Direct Upload and Pages known issues documentation.

1. Prepare the approved copy. Put the redacted portfolio in its own folder with an index.html and its images, PDFs and styles. Keep the original client files in a different place.
2. Create the Pages project. In the Cloudflare dashboard, go to Workers & Pages. Select Create application > Get started > Drag and drop your files. Enter a project name. Drop the folder. Select Deploy site. Cloudflare serves the site at <project-name>.pages.dev. If you prefer the terminal, run npx wrangler pages deploy <folder> instead.
3. Turn on an Access policy. In the project, go to Settings > General. Select Enable access policy. This setting alone protects only preview deployments, not your *.pages.dev address.
4. Extend the policy to the main address. Select Manage on the new Access policy. Under Access > Applications, select your project. Select Configure. In Public hostname, delete the wildcard (*) from the Subdomain field. Save the change. Then go back to Settings > General. Enable the access policy again to keep previews protected. Cloudflare says that the list now shows two Access policies: one for the *.pages.dev address and one for previews.
5. If you use a custom domain, protect it too. Go to Zero Trust > Access controls > Applications > Create new application > Self-hosted and private. Select Add public hostname. Choose your domain. Set the same rules. Select Create. Cloudflare gives a warning about this step. Without it, the login page appears but does not work for visitors of the custom domain.
6. Allow login by email code. In Zero Trust > Integrations > Identity providers, select Add new identity provider. Choose One-time PIN. Put the email address of each reviewer in the Access policy. Cloudflare’s One-time PIN docs say that the code expires 10 minutes after the request. Each code works once.
7. Test before you send the link. In a private window, open the *.pages.dev address, the custom domain, and a direct link to one image or PDF. Make sure that each one asks for an email first. Then test with an approved address on desktop and mobile.
8. Send a short note. Tell the reviewer what they will see and why it is protected. Tell them that a login code will come by email. Say if they can forward the link.

The same docs give one practical tip. Some email security tools open links in incoming mail and can use up the one-time code. If a reviewer sees the message “This One-Time PIN has already been used”, Cloudflare suggests that you allowlist noreply@notify.cloudflare.com. To allowlist an address is to mark it as a trusted sender.

For more detail, see the step-by-step guides for Cloudflare Pages with Access, Netlify, Vercel and GitHub Pages.

Handle Link Forwarding, Expiry, and Updates

No private link stops all copying. Try to limit casual forwarding and to make old links less useful. Expose only what each viewer needs.

Risk	Practical response	What it cannot prevent
Recipient forwards the URL	Use an email policy instead of a shared password, or change the password	Screenshots by permitted viewers
Link remains in an old email	When the review ends, remove the address of the reviewer from the policy, or change or turn off the password	Copies already downloaded
Work changes	Redeploy the folder to the same project. The URL stays the same	Reliance on an earlier download
Several audiences need access	Use separate projects, or separate Access applications with their own email lists	A recipient who describes the work elsewhere
Identity remains unclear	Switch from a shared password to email verification	Someone who verifies an address they control

A stable link helps during hiring or client review. You can fix a typo, replace a demo, or add an approved case study without sending another URL. Tell recipients about important changes. Then they can tell an update from the version that they first reviewed.

Give sensitive work a short access period. A 14-day review window is safer than a portfolio password that stays active for years. Remove access when the conversation ends.

Use Notifications and Analytics with Restraint

What you can see about visitors depends on the tool:

• Cloudflare Access records each login attempt in the Zero Trust dashboard under Logs > Access authentication logs. Each record shows the email of the user, the application, the time and whether Cloudflare allowed access. It does not record what the user did after login.
• You can turn on Cloudflare Web Analytics for a Pages project under Metrics. It shows total traffic, not individual visitors.
• DocSend and Papermark show views per visitor and per page. They can also email you when someone opens a link.
• A shared password on Netlify or Vercel tells you nothing about who entered it.

Use this data to choose the time of a follow-up. Do not use it to pressure someone five minutes after they open your work. React to each signal as follows:

• After one short visit, wait. Perhaps the person only tests if the link works.
• If the person viewed several pages and a reply is due, follow up the next business day.
• If the person downloaded a file, mention it in your scheduled follow-up. Do not list their activity.
• If the person sent a question, answer it directly. If the answer helps other people too, update the material.
• If several approved addresses logged in, expect a wider group. Offer a call or an approved supporting file.

If five hiring managers share one password, you cannot tell who viewed what. With email verification, five logins produce five named records. This difference is often more important than page-view totals.

Tell visitors that access is protected and that you use basic analytics. Clear disclosure feels professional. Quiet reactions to every click feel unsettling.

Four Private Portfolio Link Examples

Match access to the material and the relationship.

1. In an agency pitch, a branding agency cuts a 42-slide client deck to 12 approved slides. It removes client sales figures and replaces customer names with roles. It shares the password-protected portfolio with three decision-makers. It exposes 71% fewer slides and keeps the strategic work.
2. In a freelance job application, a product designer has the approval of the former client. The designer shares six anonymized screens from an unreleased prototype behind email verification. Email verification fits because several interviewers can review the screens. After a caption correction, the designer redeploys, and the same link shows the update.
3. In a consulting case study, the consultant cannot name the company or show the exact savings or the internal process map. So the consultant names the sector, uses an approved result range and redraws the diagram. The consultant sends a password separately to one prospective buyer.
4. In a founder demonstration, a founder shows software built for a regulated customer. The founder excludes real records, credentials and production integrations. The founder shares a sandbox (a separate test copy) with fictional data behind email verification. The founder asks for technical questions by email.

In each case, access control supports earlier decisions about permission and redaction. It cannot repair a disclosure that was a mistake.

Final Thoughts

A password-protected portfolio website makes it easier to present confidential work, but the gate is only one part. Permission decides if you can share. Redaction decides what visitors can learn. A password or email verification controls entry, and logs or analytics help you time the follow-up.

Keep the rules simple:

• Share the smallest approved version that proves your contribution.
• Use email verification when identity or forwarding is important.
• Use a unique password for a small, trusted audience.
• Protect every address that the site uses. Previews and custom domains are addresses too.
• When the work changes, redeploy to the same project.
• Do not share restricted or unapproved material.

The quieter and more important goal is to show good work and keep the trust that made it possible.

A docs portal with Ask AI
and support tickets

Connect a repository, or describe your product to start. Each docs site has search, Ask AI, an API console, an MCP server and support tickets.

• Publishes from GitHub on every push
• Works with Mintlify repositories
• API console from your OpenAPI file
• MCP server and llms.txt for AI agents
• Ask AI and support tickets
• Analytics for people and AI agents

Start Free→ Questions? Ask AI in our docs

No card required.