Can I add a shared password directly to an ordinary GitHub Pages site?

No. Standard GitHub Pages does not provide a native shared-password feature, so the published site remains publicly accessible unless eligible enterprise access controls are enabled.

Does using a private GitHub repository make the Pages site private?

No. Repository visibility protects the source code, while Pages visibility determines who can access the published website. Test the published URL in a signed-out or private browser window before sharing sensitive material.

When can GitHub Pages be restricted to authorized users?

GitHub Enterprise Cloud organizations can privately publish project sites from organization-owned private or internal repositories. Visitors need repository read access. Organization sites are not eligible for this private visibility option.

Is a JavaScript password prompt secure enough for confidential content?

No. Visitors can inspect browser-delivered code, discover the password logic, or request protected-looking files directly. Secure access control must authenticate the visitor before serving the site assets.

How can I share a GitHub Pages build securely with external clients?

Publish the finished static build on a host with appropriate access controls, such as Netlify, Vercel, or Cloudflare Pages with Access. Protect and test the new deployment, and disable or remove private content from any original public github.io site.

What should I remove before uploading a static build to a protected host?

Remove source maps, credentials, internal notes, configuration secrets, and development files that visitors do not need. Access controls reduce exposure, but authorized users can still view or download anything delivered to their browsers.

How should I verify that access restrictions are working?

Test the site while signed out and, where applicable, with both approved and unapproved accounts. Repeat these checks after changing visibility settings or replacing the deployed files.

GitHub Pages Password Protection and Privacy

Repository privacy and website privacy are separate
When private GitHub Pages is available
Set an eligible project site to private
When external clients need a shared password
Why a JavaScript password screen is insufficient
Verify access after publishing

Ordinary GitHub Pages has no native shared-password gate. Making the source repository private does not automatically restrict access to the published website.

GitHub Enterprise Cloud organizations can use private Pages publishing for eligible project sites. Visitors authenticate with GitHub rather than a password you send them. See GitHub’s Pages visibility documentation.

Repository privacy and website privacy are separate

A private repository controls who can read the source in GitHub. Pages publishes a website through a separate URL with its own visibility settings.

Open the published address in a private browser window. If it loads without sign-in, treat it as public even when the repository is private. Do not use an obscure URL or a search-engine exclusion as an access control.

When private GitHub Pages is available

Private Pages requires a GitHub Enterprise Cloud organization and a project site published from an organization-owned private or internal repository. Organization sites do not support this visibility option. People with read access to the repository can access the private site. Check the official eligibility rules for your account.

Set an eligible project site to private

Open the repository’s Settings.
Select Pages.
Under GitHub Pages visibility, choose the private visibility option.
Open Visit site after the change is applied.
Test with an account that has repository read access and one that does not.

If the visibility control is absent, check the organization’s plan and the repository and site types. Changing repository visibility alone is not a substitute.

When external clients need a shared password

If GitHub identity access does not fit your audience, publish the finished static build on a host with the access method you need. These guides cover provider-native controls:

Netlify Password Protection for shared-password access on eligible plans.
Vercel Password Protection for protected deployment environments.
Cloudflare Access for Pages for email codes or organization login.

Build or export the complete site, including assets, and test the protected deployment before sharing its URL. This creates a separate deployment; it does not secure an existing public github.io site. If the original contains private material, disable that public deployment or remove the material there too.

Why a JavaScript password screen is insufficient

A script can hide the visible page while leaving HTML, images, downloads, or the password-checking code accessible. Private content must be protected before it is returned to the browser.

Remove credentials, private notes, and unused development files from the build. Even an authorized visitor can inspect or download the files the browser receives.

Verify access after publishing

Test the homepage, a deeper page, and a direct download URL while signed out. For private Pages, repeat with an approved and an unapproved GitHub account. Check old URLs if you moved the site to a different host.

Repeat these checks after changing visibility or replacing the published build. Record which address is safe to share so reviewers do not continue using an earlier public link.

Get Email address for your AI agent

Create a cloud bucket and copy its <unique.id>@revdokumail.com email address.
Emails sent to this email are saved as JSON and Markdown, attachments are extracted.
Connect AI agents to read and manage saved emails and files via the API, CLI, MCP, or Skill.

Create Free Accountor connect your AI agent

const apiKey = process.env.REVDOKU_API_KEY; // Get a key at https://app.revdoku.com/account/access
if (!apiKey) throw new Error("Set REVDOKU_API_KEY first");

const response = await fetch(
  "https://app.revdoku.com/api/v1/buckets", {
    method: "POST",
    headers: {
      Authorization: `Bearer ${apiKey}`,
      "Content-Type": "application/json"
    },
    body: JSON.stringify({ bucket: { title: "My agent inbox" } })
  }
);
if (!response.ok) {
  throw new Error(`HTTP ${response.status}: ${await response.text()}`);
}
const { data } = await response.json();
const inbox = data.bucket.inbound_email;
console.log("Bucket ID:", data.bucket.id);
console.log("Email:", inbox.address);
console.log("Ready:", inbox.ready);
console.log("Open:", data.bucket.dashboard_url);
if (!inbox.ready) console.log("Receiving:", inbox.blocked_reason);