Putting a password directly in a URL is unsafe and will expose your login to anyone who can see your browser history, network traffic, or server logs

A URL with a username and password looks like this: https://username:password@example.com. Your browser will use those credentials to log you in automatically. But this method leaves your password visible in multiple places: your browser history, your device's cache, any proxy server between you and the website, the website's server logs, and anyone looking over your shoulder. Even if you delete your history, the password may remain in temporary files or backups.

The only time this format made sense was in the 1990s, when many websites had no other login system. Today, nearly every website uses a proper login form instead, and for good reason. If you see a URL with credentials in it, that's a sign the website is either very old or not following modern security practices.

Key Takeaways

  • URLs with embedded passwords expose your login to browser history, server logs, and anyone with access to your device or network.
  • Modern websites use HTML login forms instead, which send credentials through encrypted channels that don't appear in URLs.
  • If a website requires you to put a password in the URL, contact the site owner and ask them to add a proper login form.
  • Browser autofill and password managers are safer alternatives that let you log in quickly without typing passwords into URLs.

Where your password gets exposed when it's in a URL

Your browser keeps a record of every URL you visit in your history file. If someone gains access to your device — whether through theft, malware, or physical access — they can read your browser history and extract any passwords embedded in URLs. Even if you manually delete your history, forensic tools can often recover deleted files from your hard drive.

Server logs are another exposure point. When you visit a website, the server records the full URL you requested, including any credentials in it. System administrators, hackers who breach the server, or law enforcement with a warrant can all read these logs. Some websites keep logs for months or years.

If your internet connection goes through a proxy server — common in corporate offices, schools, and some public networks — that proxy also sees and may log the full URL. The same applies to your internet service provider, which can see the domain name you're visiting (though not the page path in HTTPS connections, and definitely not credentials if you use a proper login form).

How modern login forms protect your password instead

When you enter your username and password into an HTML form on a website, your browser sends that information through an encrypted tunnel called HTTPS. The password never appears in the URL. The server receives it, checks it against the stored password, and if it matches, sends back a session token — a temporary key that proves you're logged in.

This session token is what actually stays in your browser's cookies and history, not your password. The token expires after a set time (usually hours or days), so even if someone steals it, they can't use it forever. Your actual password remains secret and is never sent again unless you log out and log back in.

Server logs record that you logged in, but not your password. Browser history shows you visited the login page, but not your credentials. This is why every website built in the last 20 years uses a form instead of a URL-based login.

What to do if a website asks you to put credentials in the URL

If you encounter a website that requires you to log in by typing credentials into the URL, that's a red flag. The site is either abandoned, extremely outdated, or run by someone who doesn't understand security. Do not create an account or enter sensitive information on such a site.

If it's a website you need to use — perhaps an internal tool at work or a legacy system your organization still relies on — contact the site owner or administrator. Ask them to implement a proper login form. If they say it's not possible, ask them to at least add HTTP Basic Authentication, which is a standard protocol that lets you enter credentials in a dialog box instead of a URL. The credentials are still sent encrypted, and they don't appear in your history.

If the website is public and you have no way to contact the owner, consider whether you really need to use it. If you do, create a unique, throwaway password that you don't use anywhere else, because you cannot trust that site to keep your information safe.

Using password managers and autofill instead

A password manager like Bitwarden, 1Password, or Dashlane stores your passwords in an encrypted vault on your device. When you visit a login page, the password manager automatically fills in your username and password for you. You never type them, and they never appear in a URL.

Password managers also generate strong, unique passwords for each website, so if one site gets hacked, your password for other sites remains safe. They work across devices if you choose to sync them, and they're faster than typing passwords by hand.

Your browser's built-in password manager (Chrome, Firefox, Safari, Edge) works the same way for basic logins. It's not as full-featured as a dedicated password manager, but it's better than typing passwords into URLs or reusing the same password everywhere.

Why HTTP Basic Authentication is slightly better but still outdated

Some older websites and internal tools use HTTP Basic Authentication, a standard from 1997. When you visit the site, your browser shows a dialog box asking for a username and password. You enter them, and the browser encodes them and sends them with every request to that server.

This is safer than putting credentials in the URL because the encoded credentials don't appear in your browser history or in the URL bar. However, they're still sent with every single request, and they're only encoded, not encrypted — if someone intercepts the connection, they can decode them. HTTP Basic Authentication should only be used over HTTPS, and even then, it's considered outdated.

If you're using HTTP Basic Authentication, a password manager can still fill in the credentials for you, so you don't have to type them manually each time.

Frequently Asked Questions

Can I use a URL with credentials if the connection is HTTPS?

HTTPS encrypts the data in transit, but the password still appears in your browser history, server logs, and device cache. Encryption only protects data while it's traveling between your device and the server. Once it arrives, it's stored in plain text in those logs. HTTPS does not make URL-based credentials safe.

What if I need to log into a website automatically from a script or program?

Use the website's API if it has one, or use an API key or token instead of your password. If the website doesn't offer an API, use a headless browser tool like Selenium that can fill in a login form programmatically. Never hardcode a password into a script or configuration file.

Is it safe to share a URL with credentials with someone I trust?

No. Even if you trust the person you're sending it to, the URL may be logged by your email provider, your messaging app, your internet service provider, or your device. It's better to share login credentials through a password manager that both of you use, or to create a temporary account with limited permissions just for that person.

Why do some old websites still use this method?

They were built before modern login standards existed and have never been updated. The developers may no longer maintain the site, or the organization may not have the budget to rebuild it. This is common with internal tools, legacy systems, and websites for small organizations or government agencies.