Found a Base64 Blob in Your Logs? How to Recognise It, Decode It Safely, and Read a Basic Auth Header

Disclosure: I built the free Base64 Decoder on base64decodetool.com, and I use it for the checks in this post. Every credential and payload below is made up for illustration.

Sooner or later every developer meets a mystery string in a log line, a proxy dump or a support ticket. It looks like ZGVtb191c2Vy... and nobody remembers what wrote it. Usually it's Base64. Decoding takes seconds; the hard parts are decoding the right part of the string and not leaking anything sensitive while you do it.

This post covers three everyday cases: a Basic auth header, a binary payload you can spot from its first few characters, and a token that has lost its padding.

Step 1: Is it even Base64?

Standard Base64 uses only A–Z, a–z, 0–9, + and /, with up to two = signs at the end. The URL-safe variant swaps + and / for - and _ and often drops the =. Quick signs you're looking at Base64:

• The length is a multiple of 4, or would be after adding one or two =.
• There are no spaces, colons or quotes inside the run of characters.
• It sits after a label like Basic, base64, or a field such as payload=.

A useful trick is that common file formats start with fixed bytes, so their Base64 forms start with recognisable characters. I checked each of these in the decoder with the output set to Hexadecimal:

If a string starts with H4sI, decoding it to text will only give you noise, because it's compressed. You need the bytes, and then gunzip.

Worked example 1: reading a Basic auth header (illustrative credentials)

Say a debug log from a staging proxy contains this line. The credentials are synthetic:

Authorization: Basic ZGVtb191c2VyOk4wdC1yZWFsOmV4YW1wbGU=

HTTP Basic authentication (RFC 7617) sends username:password encoded as Base64. It is encoded, not encrypted. Anyone who can read the header can recover the password.

Input: only the token after Basic, so ZGVtb191c2VyOk4wdC1yZWFsOmV4YW1wbGU=

Calculation: 36 Base64 characters make 9 groups of 4. Each group becomes 3 bytes, so 27 bytes in theory. The single = at the end means the last group carries only 2 bytes, which leaves 26 bytes of real data.

Result: demo_user:N0t-real:example (26 characters, matching the 26 bytes).

Now split it at the first colon only. RFC 7617 doesn't allow a colon in the user-id, but the password can contain one:

• username: demo_user
• password: N0t-real:example

A script that does split(":") and keeps the second element reports the password as N0t-real, and you'll chase a "wrong password" that isn't wrong. In Python, use partition(":"). In JavaScript, use indexOf(":") and slice.

I cross-checked the result with Python's standard library:

import base64
raw = base64.b64decode("ZGVtb191c2VyOk4wdC1yZWFsOmV4YW1wbGU=").decode()
user, _, password = raw.partition(":")
print(user, password)   # demo_user N0t-real:example

The mistake to avoid: pasting the whole header

What if you paste the entire line, Authorization: Basic ..., into a decoder? I tried it with my own tool, and the result is a useful lesson. The decoder strips characters that aren't valid Base64, such as the spaces and the colon. The letters in Authorization and Basic are valid Base64 characters, though, so they stay in and shift every following group out of line.

Depending on the token length, you'll get either an "invalid Base64" error or, worse, a "successful" decode that's pure garbage. With a 36-character token that has no padding, the whole-header paste gave me 40 bytes of nonsense plus the tool's replacement-character notice. Paste only the token.

Worked example 2: a binary payload in a log (illustrative)

A webhook logger stores request bodies as Base64. One entry reads:

body_b64=JVBERi0xLjc=

Decoded as UTF-8, it reads %PDF-1.7, the start of a PDF header. Switch the output to Hexadecimal and you get 25 50 44 46 2D 31 2E 37. The 8 bytes match the 12 input characters: 3 groups × 3 bytes, minus 1 for the =.

Now compare iVBORw0KGgo=. Decoded as text it shows PNG wrapped in garbled characters, and the decoder warns that the output contains replacement characters. The Hexadecimal view shows 89 50 4E 47 0D 0A 1A 0A, the PNG signature. The rule of thumb: if the text view looks broken, switch to Hex before concluding the data is corrupt. The 89 byte isn't valid UTF-8 on its own, so a text view can't show it faithfully.

Worked example 3: missing padding

Tokens pulled out of URLs, cookies or JWTs often arrive without their =. Take ZGVtb191c2VyOg, which is 14 characters, and 14 mod 4 is 2:

• remainder 2 → add ==
• remainder 3 → add =
• remainder 1 → no valid padding exists, so the string is truncated or damaged

Adding == gives ZGVtb191c2VyOg==, which decodes to demo_user: (10 bytes). The decoder pads automatically, and Python's b64decode gives the same 10 bytes once you add the padding. A remainder of 1 is a strong hint that the string was cut off when it was copied.

Decoding sensitive data safely

Even with fake credentials, build habits that will protect real ones:

1. Prefer a decoder that runs locally. The Base64 Decoder decodes in your browser and doesn't upload your input. A terminal is just as good: echo 'TOKEN' | base64 -d.
2. Clear local history afterwards. My tool keeps a small History list in your browser's local storage, so you can re-open recent conversions. After decoding anything sensitive, open History and press Clear History.
3. Don't share links to secrets. Share Link builds a URL that contains your input (compressed into the link). That's fine for a sample string and a bad idea for a password.
4. Rotate anything that leaked. If a real Basic auth header made it into logs, the password is exposed. Change it and scrub the logs.

How to use the tool

1. Open the Base64 Decoder and make sure Decode Base64 is selected.
2. Paste only the Base64 part into the input box. With Live Conversion on, the output appears as you type.
3. Choose UTF-8 for text, or Hexadecimal or Binary for file bytes. Turn on URL-Safe Format for -/_ strings.
4. Use Copy or Download (.txt), then Clear History if the input was sensitive.

Quick recap

Decode only the token, split Basic auth at the first colon, check the Hex view when the text looks broken, and use length mod 4 to spot missing padding. Base64 hides nothing, so treat anything you can decode as already seen by whoever had the log.