How to share logs safely: remove secrets before you paste

Before you paste a log into a forum, a support ticket or any online tool, remove anything that could let someone sign in as you, identify you or reach your systems: keys, tokens, passwords, session IDs, email addresses, IP addresses and user names in file paths. Replace each with a consistent placeholder so the log still makes sense, then check it again before you send it.

Why logs leak more than you expect

Logs are written for debugging, not for sharing. A single error line can include the full request that failed, with headers, cookies and query strings. Configuration dumps can include connection strings. Crash reports often include your home folder path, which usually contains your name.

Once you paste text into a public forum or a third-party service, you lose control of it. It may be indexed, stored or seen by people you never meant to reach. The OWASP Logging Cheat Sheet lists data that should usually not be recorded in logs at all, including session identifiers, access tokens, passwords, database connection strings, encryption keys and sensitive personal data. If your log contains any of these, it should not leave your hands unchanged.

What to look for

• API keys: long random strings, often labelled api_key, apikey or x-api-key, or starting with a vendor prefix.

• Access tokens and bearer tokens: look for Authorization: Bearer followed by a long string. Tokens made of three dot-separated parts are common for web sign-ins.

• Passwords: in connection strings (user:password@host), in URLs, or in fields named password, pwd or secret.

• Session IDs and cookies: Cookie: and Set-Cookie: headers, sessionid, sid or similar values. A live session ID can let someone act as you without a password.

• Private keys and certificates: blocks that start with "BEGIN" and "PRIVATE KEY". Never share these.

• Email addresses and names: yours, colleagues' or customers'.

• IP addresses and host names: internal server names and addresses reveal how your network is laid out.

• File paths with user names: for example C:\Users\jsmith\ on Windows or /home/jsmith/ on Linux.

• Account and customer identifiers: order numbers, account IDs, phone numbers, street addresses.

• Signed URLs: links to cloud storage that include a signature or expiry parameter can give anyone with the link access to a file.

Redact by hand: a steady method

1. Work on a copy. Never edit the original log; you may need it later.

2. Cut it down first. Keep only the lines around the error, usually from a little before the first warning to the end of the failure. Less text means less to check. If you're not sure which lines matter, our guide on how to read a stack trace helps.

3. Read it line by line. Look for anything from the list above. Pay extra attention to headers, URLs and anything that looks like random characters.

4. Use consistent placeholders. Replace each value with a label that keeps its meaning, such as [API_KEY], [TOKEN], [EMAIL_1], [EMAIL_2], [IP_SERVER_A] or [USER]. If the same email appears five times, use the same placeholder every time, so the reader can still follow what happened.

5. Do not shorten secrets. Leaving the first and last few characters of a key visible is a common habit, but it still reveals part of the secret. Replace the whole value.

6. Check for secrets in odd places. Base64-encoded text, error messages that echo the input, and stack traces that include query strings can all carry secrets.

A synthetic before-and-after example from a fictional Northgate Photos sync log:

Before: 21:14:12 ERROR POST https://api.northgate.example/upload?key=ngk_8f3a91c2d7 user=jsmith@example.com path=C:\Users\jsmith\Pictures\IMG_2291.HEIC

After: 21:14:12 ERROR POST https://api.northgate.example/upload?key=[API_KEY] user=[EMAIL_1] path=C:\Users\REDACTED\Pictures\IMG_2291.HEIC

The redacted line still shows what failed and where, which is all a helper needs.

Redact with search-and-replace

Most text editors and document tools have a find-and-replace feature. Use it to catch every copy of a value you already know about, such as your user name, your email address or a host name.

1. Open the copy of the log in a plain text editor or a document tool.

2. Search for each known value (your user name, email, computer name, company domain) and use Replace all with a placeholder.

3. Search for common labels: password, token, secret, key, Authorization, Cookie, session. Inspect each match by hand.

4. If your tool supports regular expressions (search patterns), you can look for anything shaped like an email address or an IP address. Google Docs, for example, has a Match using regular expressions option under Edit, then Find and replace. Test any pattern on a small sample first, and still read the result. Patterns miss unusual formats and can also replace things you meant to keep.

Search-and-replace is a helper, not a substitute for reading. Secrets do not always follow a predictable format.

If you already shared a secret

Deleting the post is not enough; copies may already exist. Treat the secret as exposed. The OWASP Secrets Management Cheat Sheet says exposed keys should be revoked immediately and replaced with new ones. GitHub's secret scanning documentation gives the same advice: rotate the affected credential right away. In practice, that means changing the password, revoking and reissuing the key or token in the provider's dashboard, and signing out other sessions where the service allows it. If the secret belongs to your employer, tell the person responsible for security.

Before-you-paste checklist

• I am working on a copy, not the original log.

• I kept only the lines needed to show the problem.

• No API keys, tokens, passwords, private keys or connection strings remain.

• No cookies, session IDs or signed URLs remain.

• Email addresses, names, phone numbers and customer details are replaced.

• User names in file paths are replaced.

• Internal IP addresses and server names are replaced, unless the helper truly needs them.

• Placeholders are consistent, so the log still reads correctly.

• I read the final version once more from top to bottom.

• I know where the text is going and whether that service stores it.

Once it's clean, get it explained

EasyToDecode is launching soon. It will read the cleaned-up log you share, quote the lines that point to the problem, flag what is missing to diagnose it, and suggest what to check or ask next. See how it works or join the waitlist to hear when it opens.