PercentURL / URL encoding and credentials

Password Managers and URL Encoding: Keep Credentials Out of Links

Percent-encoding makes text fit URL syntax. It does not encrypt passwords, access tokens, or API keys.

A URL is easy to share—and easy to expose. Depending on the application and configuration, a password, API key, or access token placed in a URL may be recorded in browser history, application or proxy logs, monitoring systems, support tickets, or copied messages. Percent-encoding the value does not make it secret. RFC 3986 §7.5 warns that sensitive information in URIs can be exposed through browser history and intermediary systems.

URL encoding changes representation, not secrecy

Percent-encoding represents certain bytes with a percent sign followed by two hexadecimal digits. It helps characters fit URL syntax, but it does not encrypt data or control who can read it. Anyone who can see a percent-encoded value can decode it.

For example, a slash can be written as %2F. If a credential appears in a URL like this, the encoded spelling is still exposed:

https://api.example.com/report?api_key=YOUR_SECRET%2Fabc

The example is deliberately a placeholder, not a real key. %2F represents the slash character; it does not protect the value. A URL encoder or decoder is a formatting tool, not a password-protection tool.

Try a harmless example in the encoder

This ordinary text shows how encoding preserves a value’s characters without turning them into secrets. Try it in the PercentURL URL Encoder / Decoder:

Input:  q=tea & milk
Output: q=tea%20%26%20milk

%26 represents the ampersand character (&) and %20 represents a space. This is harmless example text—not a password, token, or credential. In HTML source, & is the markup spelling for a literal ampersand; it is separate from percent-encoding. Encoding changes representation only and provides no confidentiality.

Why credentials in URLs are risky

URLs are handled by systems beyond the page a person sees. Depending on the application and configuration, a sensitive query value may be recorded in browser history, web-server or proxy logs, observability tools, screenshots, support systems, or shared links. A link may also be forwarded to people who were never meant to receive the credential.

HTTPS protects data while it travels between a client and server, but it does not make a secret in a URL safe to store there. The browser, destination server, reverse proxies, logging services, or anyone who receives a copied link may still encounter it. Keeping credentials out of URLs reduces the number of places where they can be exposed.

Safer ways to handle credentials

• Web sign-in forms: Send credentials in an HTTPS-protected request body. Avoid reflecting them in redirects, page URLs, or error messages, and follow your framework’s authentication guidance.
• API credentials: Use the authentication mechanism specified in the API documentation, such as an Authorization header over HTTPS. Do not put credentials in a URL. For POST or PUT requests, sensitive data may belong in the request body or headers as documented. Apply least privilege, set an appropriate lifetime, and keep a way to revoke the credential. OWASP’s REST guidance likewise advises keeping passwords, tokens, and API keys out of URLs.
• Application secrets: Keep server-side keys in a managed secret store or protected server configuration with access controls. Do not embed private keys in public browser JavaScript, mobile app bundles, or source repositories.
• Marketing links: Use campaign labels that contain no personal or account data. Keep email addresses, reset links, private customer details, and credentials out of shareable query strings.
• Shared access: Use scoped, short-lived credentials or an access-grant workflow where possible. Give each person or service only the permissions it needs, and set an expiration or revocation path.

These practices complement HTTPS, access controls, and careful logging. OWASP’s Logging Cheat Sheet also covers protecting credentials and session identifiers in logs.

If a credential has already appeared in a link

Assume it may have been seen or stored. Take these steps promptly:

1. Revoke or rotate it. Invalidate the exposed API key, token, session, or reset link. If a password was exposed, change it and change it anywhere it was reused. Invalidate a related session where supported.
2. Issue a replacement safely. Use a fresh, appropriately scoped credential and deliver it through an approved secure channel. Do not reuse the exposed value.
3. Review access and security logs. Look for unexpected use from the time the link was created or shared. Follow your organization’s incident-response process if a work account, production service, or customer data may be involved.
4. Remove avoidable copies. Delete the link from messages, tickets, documents, pages, or repositories where you control it. Ask system owners to handle log retention or redaction under their procedures. Deleting a visible copy cannot guarantee every cached, forwarded, or logged copy is gone—keep the credential revoked.
5. Prevent a repeat. Fix the link-generation or logging behavior, and add review checks so secrets are not written into URLs.

Where a password manager fits

A password manager can help people create and keep unique account passwords in a separate vault instead of reusing or sending them in messages. It does not make a credential safe after it is placed in a URL, and it cannot remove that URL from logs, history, or recipients’ devices. Password managers are one part of account hygiene; keeping credentials out of URLs and rotating exposed secrets remain necessary.

Common questions

Does URL encoding hide a password?

No. Percent-encoding changes how some characters are represented. It is not encryption, and the value can be decoded.

Does HTTPS make a token in a URL safe?

No. HTTPS protects data in transit, but the URL may still be visible to the browser, destination infrastructure, logs, monitoring tools, or anyone who receives a copied link. Keep credentials out of URLs.

Should I put an API key in a query parameter if the endpoint uses HTTPS?

No. Follow the API’s documented authentication method, such as an Authorization header over HTTPS. OWASP advises that passwords, security tokens, and API keys should not appear in URLs.

What if I already shared a password-reset or sign-in link?

Invalidate the link or token if possible, start a fresh reset flow, and review relevant access logs. If the link contains a password or reusable API credential, change or revoke that credential. Do not rely on deleting the message alone.

Can a password manager prevent URL leaks?

No. A password manager can help generate and store credentials, but URL construction, application logs, and incident response need separate safeguards.