Are HTTPS URLs encrypted?
HTTPS protects URL paths and query strings in transit. Learn what remains visible to networks, TLS proxies, servers, and logging systems.
HTTPS encrypts the URL path, query string, headers, and body between the client and the system that terminates TLS. With certificate verification working correctly, a passive observer cannot simply read that HTTP content. The browser, application server, and any CDN or proxy that terminates TLS can still see it.
What HTTPS protects
Within a TLS connection, HTTP data includes:
- The path and query string, such as
/orders?id=123. - Request bodies, including forms, JSON, and uploads.
- Response bodies, including pages and API results.
- Cookies and other HTTP headers.
The #fragment is different: browsers do not send it as part of the HTTP request target. Page scripts can read it and send it elsewhere, so it is not a safe place to keep a secret.
What an observer can still learn
| Information | Visibility on the network |
|---|---|
| Hostname | May be disclosed by unencrypted DNS or ordinary TLS Server Name Indication (SNI) |
| Destination IP and port | Visible to observers on that network path |
| Path and query string | Encrypted in transit; visible at TLS endpoints |
| Request and response content | Encrypted in transit; visible at TLS endpoints |
| Traffic volume and timing | Still observable, even though the payload is encrypted |
Encrypted DNS and Encrypted Client Hello (ECH) protect different parts of the connection setup. ECH can conceal the real SNI name when the client, DNS configuration, and server support it. Neither mechanism hides the destination IP or all traffic patterns. See the TLS 1.3 specification and Cloudflare's ECH documentation.
TLS 1.3 early data remains encrypted, but it has replay risks. Encryption alone does not make every request safe to repeat.
What this means for applications
Keep passwords and long-lived access tokens out of URLs. URLs can persist in browser history, access logs, proxy logs, screenshots, and shared links. Use the authentication protocol's headers or a request body for sensitive values, and redact those locations too.
Review what your logging and tracing systems capture. Nginx access logs and APM URL fields may contain decrypted paths and parameters. Avoid recording secrets at the application or proxy. When collecting with Guance, a local Pipeline can process fields before DataKit uploads them. Test both the parsed fields and the original message; adding a redacted field does not remove an unredacted copy elsewhere. A central Pipeline runs after upload and cannot replace protection before collection leaves the host.
Monitor certificates at the points where TLS actually terminates. A CDN edge certificate and an origin certificate belong to separate connections, and an expiration can affect either one.
Common questions
Why can my company's network administrator see the page I visited?
An authorized HTTPS inspection proxy may terminate TLS using a corporate CA trusted by your device, inspect the request, and establish another connection upstream. Alternatively, an administrator may infer the destination from DNS, SNI, or traffic patterns. That inference is not the same as reading a decrypted path and may be wrong.
Does HTTPS protect me from phishing?
It protects the connection to the authenticated hostname. It does not establish that the business behind that hostname is trustworthy; phishing sites can obtain valid certificates too.
Does a URL fragment reach the server?
Not as part of the ordinary HTTP request target. JavaScript, browser extensions, or other software can still read and transmit it. Treat fragments as client-visible data.
Contact us
Join the community
to join the community
Try Guance
Start online and pay only for what you use.
Get startedChoose a Guance plan