Putting a password directly in a URL is unsafe and most modern browsers and servers will reject it

You can technically write a password into an HTTPS URL in the format https://username:password@example.com, but you should not do this. Browsers stopped displaying passwords in URLs years ago because the practice exposes your credentials in multiple places: in your browser history, in server logs, in any screenshots you take, and in the address bar if someone looks over your shoulder. Even though HTTPS encrypts the connection between your device and the server, the password itself becomes visible in plain text everywhere else.

Most websites and APIs no longer accept passwords in URLs at all. They use other methods instead — tokens, API keys, session cookies, or dedicated login forms — that keep your credentials out of the address bar entirely. If you are trying to access something that seems to require a password in the URL, you are almost certainly using the wrong method.

Key Takeaways

  • Passwords in URLs appear in browser history, server logs, and screenshots, making them visible to anyone with access to those records.
  • Modern websites reject passwords in URLs and require you to log in through a form or provide credentials in a separate, encrypted request.
  • If you need to automate access to a service, use an API key, bearer token, or OAuth token instead of embedding a password.
  • HTTPS encrypts data in transit but does not protect a password that is typed into the address bar or stored in your browser history.

Why browsers and servers stopped accepting passwords in URLs

When you type a URL with a password into your browser, that password gets saved in your browser history. Anyone who uses your computer can open your history and see it. The same password also appears in server logs — the record the website keeps of every request it receives. System administrators, security auditors, or anyone with access to those logs can read it.

If you share a link, take a screenshot, or use a tool that logs your activity, the password ends up in those places too. A password in a URL is essentially a password written on a sticky note and left on your desk. HTTPS protects the password while it travels from your computer to the server, but it does not protect it anywhere else.

Because of these risks, browsers like Chrome, Firefox, and Safari now strip passwords out of the address bar or refuse to use them altogether. Most servers do the same — they will not accept authentication credentials in the URL even if you try to send them.

How to send credentials securely instead

The standard method is a login form. You enter your username and password into form fields on a webpage, and your browser sends them in the body of an HTTPS request, not in the URL. The server checks them, and if they are correct, it creates a session — a temporary record that says "this person is logged in." Your browser stores a session cookie, a small token that proves you are logged in without revealing your password.

For automated access — scripts, applications, or tools that need to connect to a service without a human typing in a password — most services provide an API key or bearer token. You generate this token once in your account settings, then include it in the header of your request instead of in the URL. The token can be revoked or rotated without changing your actual password, and it can be restricted to specific permissions or IP addresses.

Some services use OAuth, a system where you log in once on the service's own website, and it gives your process a token to use on your behalf. You never give your password to the process at all. This is what happens when you see "Sign in with Google" or "Sign in with Facebook" on a website.

What to do if a service asks for a password in the URL

If a website or API documentation tells you to put your password in the URL, that is a sign the service is either very old, poorly designed, or not legitimate. Do not do it. Instead, look for a login form on the website, or check the documentation for an API key or token option.

If you are setting up an automated task — a script that needs to read files or pull data — and the only method you can find is a password in the URL, contact the service's support team and ask for an API key or token option. Most modern services have one, even if it is not documented clearly. If they do not, consider whether you trust that service with your password at all.

How HTTPS protects your connection but not your URL

HTTPS encrypts everything that travels between your computer and the server — including the URL itself. Someone on your WiFi network cannot see what website you are visiting or what you are sending to it. But encryption stops at both ends. Once the data reaches the server, it is decrypted and stored in logs. Once it reaches your computer, your browser stores it in history.

A password in a URL is encrypted during transit but visible everywhere else. A password sent in a form field is also encrypted during transit, but the difference is that the browser and server are designed to handle it securely — the browser does not save it in history, and the server does not log the request body the same way it logs URLs.

Protecting yourself if you have already used a password in a URL

If you have typed a password into a URL in the past, change that password when ready. Clear your browser history to remove it from your device. If you used the URL in a script, email, or message, delete those records too. If the service has a login form, use that instead going forward.

Check whether your browser has synced your history to the cloud. If you use Chrome, Firefox, or Safari with account sync enabled, your history may be stored on the company's servers. You can turn off sync, but the history that was already uploaded may remain there. For maximum safety, change the password and assume it may have been seen.

Frequently Asked Questions

Can someone see my password if I put it in a URL on HTTPS?

Not during transmission — HTTPS encrypts it while it travels. But the password appears in your browser history, server logs, and any screenshots or records of the URL. It is visible to anyone with access to those places, which is why you should not do it.

What is the difference between a password and an API key?

A password unlocks your entire account. An API key is a separate credential that you generate in your account settings and can restrict to specific tasks or revoke without changing your password. If an API key is stolen, you can delete it without losing access to your account.

Do I need to change my password if a website asks me to put it in a URL?

Not necessarily, but it is a red flag. If a legitimate service asks you to do this, contact their support and ask for a safer method. If it is a suspicious or unknown service, do not use it at all.

What should I do if I see a URL with someone else's password in it?

Do not click it or share it further. If it is a work-related URL, tell the person who sent it that they should change that password and use a login form instead. If it is from an unknown source, it may be a phishing attempt.