People search for ways to “decrypt a URL” when a link looks like noise. In nearly every case the link is not encrypted at all. It is encoded: rewritten in a different alphabet so it travels safely. Encoding is reversible by anyone, with no key. Encryption needs a key. Telling the two apart tells you whether you can read the link, and which tool to use.
Encoding, encryption, hashing and signing
These four are often mixed up. What matters for a link is whether you can get the original back.
| Technique | Needs a key? | Reversible? | Looks like |
|---|---|---|---|
| Percent-encoding | No | Yes, by anyone | %20, %2F, %C3%A9 |
| Base64 or Base64URL | No | Yes, by anyone | letters and digits, often ending in = |
| Signing (for example a JWT) | Only to forge or verify | The content is readable; the signature only proves it was not changed | three parts separated by dots |
| Hashing | No | No, by design | a fixed-length string of hex digits |
| Encryption | Yes | Only with the key | random-looking, no readable pattern |
How to tell what you have
- Percent signs followed by two hex digits. This is percent-encoding. Paste it into the URL Decoder. For example
https%3A%2F%2Fexample.com%2Fprivate%3Fid%3D42decodes tohttps://example.com/private?id=42. - Only letters, digits, and sometimes + / - _ or a trailing =. This is probably Base64. Decode it with the Base64 tool. For example
aHR0cHM6Ly9leGFtcGxlLmNvbS9wcml2YXRlP2lkPTQyis Base64 forhttps://example.com/private?id=42. - Three chunks separated by dots, the first starting with eyJ. This is a JSON Web Token. The first chunk,
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9, decodes to{"alg":"HS256","typ":"JWT"}. Open it in the JWT Decoder. - A fixed-length run of hex digits (commonly 32, 40 or 64 characters) is usually a hash. A hash is one-way, so there is nothing to decode.
- Random-looking text with no pattern is either encrypted or just a random ID. Without the key, or access to the server that issued it, you cannot read it.
Links that contain another link
Many links look scrambled because a whole address is stored inside a parameter. The destination is simply percent-encoded:
https://example.com/out?url=https%3A%2F%2Fshop.example.org%2Fitem%3Fid%3D7%26ref%3DmailHere the url parameter holds the real destination. Decoding the value gives https://shop.example.org/item?id=7&ref=mail. The URL Parser splits a link like this into its parameters and flags values that contain another URL.
Links you cannot decode
- Short links and tracking redirects with a random token. The token is a database key. The destination exists only on the server.
- Session and signed tokens. They are meant to be opaque to the user. A signed link proves it was issued by the server; it does not hide its contents unless it is also encrypted.
- Vendor-specific wrappers. Some email security gateways rewrite links in their own format. Use the vendor's own tool for those.
Decoding is not secrecy
If something is only encoded, it is not protected. Do not put passwords, API keys or personal data in a URL expecting encoding to hide them. Anyone who sees the link can read it. If you need secrecy, the data must be encrypted with a key, and ideally kept out of URLs altogether, because URLs end up in browser history, server logs and referrer headers.