Git stopped accepting account passwords over HTTPS a while back, so typing yours at a prompt today just gets rejected. A personal access token takes its place. You create it under Settings, Developer settings, Personal access tokens, Generate new token, and it can only do what the scopes or permissions you select allow. It works for Git over HTTPS and for the GitHub API.
GitHub’s own documentation recommends the fine-grained type over the classic type whenever possible (GitHub Docs, 2026).
Plenty of walkthroughs still send beginners to classic, which reaches every repository the account can access. A fine-grained token stays limited to one owner and the repositories you name.
What Is a GitHub Token and Which Types Exist?
Scripts and command-line work now run on tokens, since password-based authentication for Git has been removed. Whether you call the GitHub API or run Git commands over HTTPS, the token goes where the password used to go. It carries limited scopes or permissions and, if you set one, an expiration date.
A token never grants more than its owner can do. A classic token with the admin:org scope still gives no administrative access to an organization if you are not an owner of it (GitHub Docs, as of October 2026).
The prefix on a token tells you which kind you are holding.
- Fine-grained personal access tokens (github\pat\) can be limited to one user or organization, and optionally to named repositories
- Classic personal access tokens (ghp\_) reach every repository your account can reach
- OAuth access tokens (gho\_) go to an OAuth app after you authorize it
- GitHub App tokens come as user (ghu\), installation (ghs\) and refresh (ghr\_) types
Only the first two get created by hand. The rest come from an app, an authorization flow or a workflow run.
It is standard token-based authentication, except GitHub issues several types with different lifetimes and reach.
Workflows get their own token too. Jobs run by GitHub Actions receive a built-in GITHUB\_TOKEN that only reaches the repository containing the workflow.
One recent change is worth knowing about. Starting April 27, 2026, GitHub began a staged rollout of a stateless format, ghs\_APPID\_JWT, for newly minted GitHub App installation tokens. Code that assumes a 40-character length can break (GitHub Docs).
Do You Need a Personal Access Token at All?
Often not. GitHub’s documentation says to look for a safer method first, because personal access tokens carry the same risks as passwords.
On your own machine, GitHub CLI or Git Credential Manager handles the login. Inside a GitHub Actions workflow, the built-in GITHUB\_TOKEN does the job, and you set its permissions with the permissions key.
Access for an organization, or for an integration that will run for a long time, fits a GitHub App better. Personal tokens are meant to act on your own behalf.
The command-line route is the quickest. The GitHub CLI signs you in through the browser with gh auth login, so no password prompt appears.
SSH is the other option for Git. After adding an SSH key to your account, pushes and pulls skip tokens entirely. SSH covers Git operations only, so scripts that call the REST API still need a token or an app.
You do need a token when a script or tool calls the REST API as you, outside Actions, or when a workflow has to change resources beyond its own repository. A third-party integration that asks for one and offers no app-based login is the remaining case.
Fine-Grained or Classic: Which Token Type Should You Pick?
Pick fine-grained unless you run into one of the documented gaps. GitHub recommends it over classic whenever possible (GitHub Docs, as of October 2026).
| Criterion | Fine-grained | Classic |
|---|---|---|
| Prefix | github\pat\ | ghp\_ |
| Repository reach | One owner, selected repositories | Every repository you can access |
| Permission model | Per-resource read or write | Broad scopes such as repo |
| Organization control | Owners can require approval | Owners can block it, requests then fail with 403 |
| Public repositories you do not belong to | Read-only | Write access possible |
Fine-grained tokens can’t do everything yet. GitHub’s list of gaps includes contributing to public repositories where you are not a member, and contributing as an outside or repository collaborator. They also can’t reach several organizations at once, Packages, the Checks API, or Projects owned by a user account.
If your task hits one of those, use a classic token. Otherwise skip it.
Plenty of beginner guides, including a GitHub community answer, send newcomers straight to a classic token with the repo scope. It works, but it hands over every repository you can reach, and an organization can shut it out.
How to Create a Fine-Grained Personal Access Token
Open Settings, then Developer settings, then Fine-grained tokens, and click Generate new token. The token only reaches the owner, repositories and permissions you select on that form.
- Verify your email address if you have not yet.
- Click your profile picture in the upper-right corner, then Settings.
- Click Developer settings in the left sidebar.
- Under Personal access tokens, click Fine-grained tokens, then Generate new token.
- Enter a token name and choose an expiration.
- Select a resource owner: your account or an organization.
- Under Repository access, keep it minimal. Choose Only select repositories to name them.
- Under Permissions, grant only what the task needs.
- Click Generate token and copy the value before leaving the page.
Infinite lifetimes are allowed for the expiration, though an organization or enterprise maximum lifetime policy can block them. An account can hold 50 fine-grained tokens. Past that, GitHub points you to a GitHub App (GitHub Docs).
Pre-Fill the Token Form With a URL
A link can fill in the form for you, which helps when you hand the same setup to a teammate.
https://github.com/settings/personal-access-tokens/new?name=Repo-reading+token&expires_in=45&contents=read
nametakes up to 40 charactersdescriptionallows up to 1024 characterstarget_nameis the user or organization that owns the repositoriesexpires_inruns from 1 to 366 days, or none. The default is 30 days, or less under an organization lifetime policy- Permissions are written as contents=read, pull\_requests=write and so on
What Happens When an Organization Requires Approval
If the resource owner is an organization that requires approval, the token shows as pending after you generate it. Until an administrator reviews it, the token reads public resources only.
Organization owners are approved automatically. Everyone else can add a justification on the form, which tends to speed the review along.
How to Create a Classic Personal Access Token
Open Settings, then Developer settings, then Tokens (classic), and choose Generate new token (classic). Select the repo scope to reach repositories from the command line.
- Verify your email address if you have not yet.
- Click your profile picture, then Settings.
- Click Developer settings in the left sidebar.
- Under Personal access tokens, click Tokens (classic).
- Click Generate new token, then Generate new token (classic).
- Give the token a descriptive name in the Note field.
- Pick an expiration from the presets, or click Custom and enter a date.
- Select scopes. A token with no scopes reads public information only.
- Click Generate token and copy it with the clipboard icon.
- If the organization uses SAML single sign-on, authorize the token for it.
GitHub does not show the token again once you leave the page. Lose it and you generate a new one.
The reach is the catch. A classic token touches every repository you can access, personal ones and organization ones alike.
It also fails in one situation you can’t fix from your side. An organization that disabled classic tokens answers every request with a 403, so you’d need a fine-grained token, a GitHub App or an OAuth app there. GitHub also removes any classic token left unused for a year.
Which Permissions or Scopes Does Your Task Need?
Match the permission to the verb in your task. Reading code needs contents read, pushing needs contents write, and workflow files need their own permission on top.
| Task | Fine-grained token | Classic token |
|---|---|---|
| Read repository contents | contents: read | repo (public\_repo for public only) |
| Push code | contents: write | repo |
| Open a pull request | pull\_requests: write plus contents: write | repo |
| Edit workflow files | workflows: write | repo plus workflow |
Fine-grained levels stack. Write always includes read and admin always includes write, so one level covers a task that both reads and changes things (GitHub Docs, as of October 2026).
The workflows permission has no read level, only write.
When a script has to push code to a repository over HTTPS, contents write is the only repository permission it needs.
Anything that goes further, such as opening a pull request from a script, adds pull\_requests write on top of it.
On the classic side, a handful of scopes cover most real use.
- The repo scope gives full access to public and private repositories, plus organization-owned projects, invitations, team memberships and webhooks
- With public\_repo you get the same code access, but only for public repositories
- workflow lets you add and update workflow files
- read:org is read-only access to organization membership, organization projects and team membership
The repo scope reaches further than its name suggests, because it manages organization-owned resources too. That is the practical argument for public\_repo or a fine-grained token.
GitHub’s scope documentation also describes two response headers. X-OAuth-Scopes lists the scopes a token carries, and X-Accepted-OAuth-Scopes lists what the action checks for.
Authorizing a Token for SAML Single Sign-On
A classic token gets authorized after you create it. A fine-grained token is authorized during creation, before access to the organization is granted.
Skip the step and a request to a single-sign-on organization returns 404 or 403. The 403 response carries an X-GitHub-SSO header with an authorization URL that expires after one hour (GitHub REST API documentation).
How to Use a GitHub Token With Git, the API and the CLI
Git over HTTPS asks for a password, and that is where the token goes. Run git clone with an HTTPS URL, type your username, then paste the token at the prompt.
The prompt looks like a password field, but the username is a formality. GitHub authenticates with the token.
API calls take it in an Authorization header instead. With the GitHub CLI, run gh auth login and pick the token or browser flow.
Cloning a private GitHub repository over HTTPS is the quickest way to confirm a new token works.
Plenty of tutorials embed the token in the clone URL. GitHub’s REST API security guidance says not to pass a personal access token as plain text on the command line.
Git forgets the token after each prompt unless something caches it. GitHub recommends GitHub CLI or Git Credential Manager for that, and Git Credential Manager runs the browser login, OAuth and 2FA for you, so no token is created by hand.
For API calls, the token goes in the Authorization header with the Bearer scheme.
curl --request GET \
--url "https://api.github.com/octocat" \
--header "Authorization: Bearer YOUR-TOKEN" \
--header "X-GitHub-Api-Version: 2026-03-10"GitHub’s endpoints follow the conventions of a RESTful API, so any HTTP client can send that header.
Most endpoints accept either Authorization: Bearer or Authorization: token. A JSON web token must use Bearer.
Version 2026-03-10 is the latest API version in GitHub’s documentation as of October 2026.
One thing trips people up. A personal access token cannot authenticate an SSH remote, so switch the remote URL from SSH to HTTPS before you expect it to work.
Setting Expiration, Storing and Revoking a Token
Pick an expiry that matches the job, keep the token in a secret store instead of in code, and delete it the moment it leaks. A revoked or expired token cannot be restored, only replaced.
Choose an Expiration
GitHub’s guidance is to set the expiration to the shortest time you will need the token. When the date arrives, GitHub revokes the token automatically.
A short custom date beats no expiration for anything you can recreate in a minute.
A one-off script needs a few days. A side project can stretch to a few months. For a CI job, pick a rotation schedule you will actually keep.
Store the Token Safely
A password manager works, as do GitHub Actions secrets and Codespaces secrets. GitHub’s guidance also names secret managers such as Azure Key Vault and HashiCorp Vault.
Keep the token out of source code, and out of every repository you push to, private ones included. Unencrypted email or chat is out too.
If nothing else is possible, a .env file works as long as it is encrypted and never pushed. List it in a gitignore file so a careless commit cannot include it.
The same habits apply to keeping an API key out of a repository, and a token is just another key.
Two GitHub features protect tokens, and both skip private repositories by default. Push protection for users is on by default and stops secrets from reaching public repositories, and a token pushed to a public repository or gist is revoked automatically.
A token committed to a private repository gets neither safeguard unless repository-level push protection is enabled. It is off by default and needs GitHub Secret Protection (GitHub Docs, push protection and token expiration pages).
Delete or Revoke a Leaked Token
- Generate a new token.
- Replace the old token everywhere it is stored or used.
- Delete the old token under Developer settings, in the Fine-grained tokens or Tokens (classic) list.
Deleting a token that created a deploy key also deletes that deploy key. Check for that before you clean up.
If you suspect the whole account is exposed, or a laptop was lost, revoke all credentials at once from account settings.
Found someone else’s exposed token? Anyone can submit a revocation request through the REST API, and the request needs no authentication.
Lifecycle Limits Worth Knowing
- A GitHub App user access token lasts 8 hours by default before its refresh token is needed
- An OAuth app keeps 10 tokens per user, application and scope combination, and GitHub revokes an existing one after that
- Creating more than 10 tokens per hour for an OAuth app triggers a re-authorization prompt instead of a revocation
- The revocation API covers 5 prefixes in GitHub’s documentation: ghp\_, github\pat\, gho\, ghu\ and ghr\_
Why Is My GitHub Token Not Working?
Most failures trace back to missing permissions, unauthorized single sign-on, an endpoint the token type does not support, stale cached credentials, or a token that has already expired.
- A 404 on a repository you can see usually means missing access rather than a missing repository, since the API returns 404 or 403 when a token lacks permission (GitHub Docs)
- If results are missing for some organizations, you may have several of them and an unauthorized classic token. The API skips the protected ones, and the X-GitHub-SSO header reports partial results with their organization IDs
- A 403 that follows a few 401 errors comes from GitHub temporarily rejecting every authentication attempt for that user after several invalid-credential requests in a short period, valid credentials included
- A few REST endpoints work only with classic tokens, so when one refuses a fine-grained token, check the endpoint’s reference page for the token types and permissions it accepts
- If Git still uses the old password, cached credentials are winning over the new token. Delete the GitHub entry in Windows Credential Manager or update the macOS Keychain entry
- A token that worked yesterday may have expired or been revoked, and either one can no longer authenticate Git or API requests. A revoked token leaves an oauth\_authorization.destroy entry in the security log
Read the HTTP status first, then the X-GitHub-SSO header, then the token’s expiry date in Developer settings. That order finds the cause faster than regenerating the token on a guess.
GitHub Token FAQ
How many GitHub tokens can I create?
Fine-grained tokens are capped at 50 per account. Past that, GitHub steers you toward a GitHub App for automations that need more credentials (GitHub Docs, as of October 2026).
Can I see my token again after I create it?
No. GitHub shows the value once, right after generation.
If you lose it, create a new token, update whatever used the old one, and delete the old entry in Developer settings.
Is it possible to restore an expired token?
No. An expired or revoked token cannot authenticate again, and GitHub offers no way to bring it back. Create a new one with the same permissions and a fresh expiration date.
How many API requests can I make with a token per hour?
Requests made with a personal access token count against a personal limit of 5,000 per hour, while unauthenticated requests get 60 per hour (GitHub REST API documentation, 2026).
The built-in GITHUB\_TOKEN in Actions gets 1,000 per hour per repository.
Should I use a personal access token or an SSH key for Git?
For plain Git work from your own machine, an SSH key is simpler, because it involves no token and no expiry date. Choose the token when you need HTTPS, or when a script calls the GitHub API.
Can I share one token with my team?
Don’t. A personal access token acts as you, so everything done with it is attributed to your account.
GitHub recommends a GitHub App for shared access. If credentials must be shared, keep them in a secure shared system and never send them over unencrypted chat or email.
When a GitHub App Beats a GitHub Token
A GitHub App should replace a GitHub token once a second person or a scheduled job depends on the access. Rate budgets show why.
Every request from your personal access token, and from any app acting for you, shares one 5,000 per hour allowance. Outside GitHub’s enterprise tier, an app installation scales to a ceiling of 12,500 per hour, 2.5 times that (GitHub REST API documentation, as of October 2026).
Extra budget arrives at 50 requests per hour for each repository beyond 20 and each user beyond 20, so smaller installations stay at 5,000.
The trade-off is setup, since an app needs registration and a private key. A fine-grained token still wins for solo scripts.
Stay on a fine-grained token while you work alone. Once a team depends on the job, move to a GitHub App, and delete the old token after the app runs cleanly.
- Notepad++ Android Options: Apps That Come Close - October 21, 2026
- MongoDB Cheat Sheet - October 20, 2026
- Adding AI Video Generation to a Software Product: Architecture, Cost Guardrails and QA - October 20, 2026
