The Burp Suite Decoder is your Swiss Army knife for wrestling with data formats, but its real magic isn’t just converting between them; it’s revealing the intent behind that data when it’s trying to hide in plain sight.
Let’s say you’ve intercepted a request, and buried within it is a string that looks like this: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. Your first instinct might be, "What is this gibberish?" This is where the Decoder shines.
Open up Burp Suite, paste that string into the Decoder tool, and select "Decode as…" -> "URL". You’ll see it transform into eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c. Still looks like gibberish, right? That’s because URL encoding is often applied after another encoding.
Now, with the same string still selected in the Decoder, try "Decode as…" -> "Base64". Boom.
{
"alg": "HS256",
"typ": "JWT"
}
This is the first part of a JSON Web Token (JWT). The Decoder has just unmasked the header. If you take the next segment of the original string (eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ) and decode that as Base64 as well, you get the payload:
{
"sub": "1234567890",
"name": "John Doe",
"iat": 1516239022
}
And the final part? That’s the signature, used to verify the token’s integrity. The Decoder isn’t just a simple text transformer; it understands common data serialization and encoding schemes used in web applications.
The core problem the Decoder solves is data obfuscation. Applications use encoding to safely transmit data within URLs, form parameters, or even within JSON/XML bodies. They also use it for things like creating unique identifiers or embedding structured data in a single string. When you’re testing an application, you’ll encounter data that needs to be understood before you can manipulate it.
Here’s a typical workflow:
- Intercept a request/response: Use Burp Proxy to capture traffic.
- Identify interesting data: Look for parameters, headers, or body content that seem encoded or structured. Common candidates are
token,session_id,data,payload, or any Base64-looking strings. - Send to Decoder: Right-click the data and select "Send to Decoder."
- Experiment with decoding: In the Decoder tab, use the "Decode as…" dropdown. Try "URL", "Base64", "HTML", "Hex", "Gzip", "Deflate", and "ASCII" in combination. Often, data is encoded multiple times (e.g., Base64 then URL-encoded). Keep decoding until you see human-readable or structured data.
Let’s see this in action. Imagine you find this in a cookie: session=W1VzZXJJRD1hZG1pbixVc2VyTmFtZT1BZG1pbixSb2xlPW1hbmFnZXJd.
In Burp Proxy, right-click W1VzZXJJRD1hZG1pbixVc2VyTmFtZT1BZG1pbixSb2xlPW1hbmFnZXJd and select "Send to Decoder."
In the Decoder tool:
- Select "Decode as…" -> "Base64".
The output will be: [UserID=admin,UserName=Admin,Role=manager]
This is a simple, custom format. Now you know the session contains user details. You can easily modify this string, re-encode it (select "Encode as…" -> "Base64"), and send it back in a repeater to test access controls.
Another common scenario is finding encoded JSON within a POST body:
data=%7B%22productId%22%3A%22123%22%2C%22quantity%22%3A1%7D
Send data=%7B%22productId%22%3A%22123%22%2C%22quantity%22%3A1%7D to the Decoder.
- Select "Decode as…" -> "URL".
Output:
{"productId":"123","quantity":1} - Now, with that new string selected, select "Decode as…" -> "JSON". Output: The JSON will be pretty-printed, making it easy to read.
The mental model to build is that the Decoder is a multi-layered onion. Each "Decode as…" operation peels off one layer of encoding. You’re not just transforming characters; you’re reversing a process that was applied to make data safe or compact. Understanding the order of encoding is key. Base64 is often followed by URL encoding because Base64 can produce characters (+, /, =) that are problematic in URLs.
The one thing that catches many people out is when data is encoded multiple times using the same method. For instance, you might see something like YWFhYQ==. Decoding this once as Base64 gives you YWFh. Decoding that again as Base64 gives you YWF. Decoding that again gives you YQ. The Decoder will happily do this for you, and you can keep applying the same decode operation repeatedly to see the full extent of the encoding. Just keep selecting "Decode as…" -> "Base64" (or your chosen encoding) until the output stops changing.
Once you’ve mastered decoding, the next logical step is understanding how to generate these encoded strings yourself to craft malicious or manipulative payloads, which leads you into the realm of crafting custom attack vectors and leveraging Burp’s Intruder for brute-force encoding/decoding scenarios.