codeshot.io

How to redact API keys and secrets in screenshots before you share them

Where API keys, tokens and personal data hide in terminals, logs, requests and .env files, how to redact them safely, and what to do after a leak.

SecurityBy the Codeshot team6 min read

Quick answer: Don't blur or pixelate secrets in an image — replace them in the text before the image is created. Swap real keys for placeholders like sk_test_your_key_here, use example.com domains and documentation IP ranges, and read every line of the final image. If a real secret is ever posted, revoke it immediately: deleting the post is not enough.

Leaked credentials rarely come from a dramatic hack. Far more often, someone shares a screenshot of a terminal, a log or an API request to ask for help or show progress, and a token sits in plain sight. Automated scanners look for exactly this, and images are routinely run through optical character recognition (OCR), so a key in a picture is barely safer than a key in plain text.

This guide covers what counts as a secret, where secrets hide in the content developers share most, how to redact them properly, and how to respond when one slips through.

What counts as a secret?

The obvious items are easy to spot. The less obvious ones cause most incidents.

Type Examples Why it matters
Credentials API keys, OAuth client secrets, personal access tokens, passwords, SSH keys Direct access to accounts and systems
Session material Cookies, bearer tokens, JWTs, CSRF tokens, pre-signed URLs Lets someone act as a logged-in user
Connection strings postgres://user:password@host/db, Redis and MongoDB URLs Usually embed a username and password
Infrastructure details Internal hostnames, private IPs, account and project IDs, bucket names Help an attacker map your systems
Personal data Customer names, emails, addresses, order and user IDs Privacy and legal obligations

Many providers prefix their keys so leaks are easy to detect: Stripe secret keys start with sk_live_ or sk_test_, GitHub personal access tokens with ghp_, Slack bot tokens with xoxb-, and AWS access key IDs with AKIA. If you see one of these prefixes in something you are about to share, stop.

JSON Web Tokens deserve a special warning. A JWT looks like random characters, but its middle section is just Base64URL-encoded JSON. Anyone can decode it and read the claims — often a user ID, email and role — and if it has not expired, it may still grant access.

Where secrets hide in the content you share

Terminal sessions

  • Commands that take credentials as flags: curl -H "Authorization: Bearer …", mysql -u root -pPassword.
  • The output of env, printenv, export or set.
  • Cloud CLI output that prints account IDs, access key IDs or temporary session tokens.
  • The prompt itself, which often shows your username, machine name and current directory.
  • Previous commands still visible above the one you meant to capture.

Logs and stack traces

  • Request logs that record full URLs, including tokens in query strings like ?access_token=….
  • Startup output that dumps an entire configuration object.
  • Database errors that include the failing connection string or a query with real customer values.
  • File paths containing usernames, such as /home/jane.doe/….

HTTP requests and API responses

  • Authorization, Cookie, Set-Cookie and X-Api-Key headers.
  • Webhook signing secrets and signature headers.
  • Response bodies containing other users' data or tokens issued by the server.

.env and configuration files

  • Every value in a real .env file should be treated as sensitive until proven otherwise.
  • Commented-out keys (# OLD_STRIPE_KEY=…) are just as dangerous — old keys are frequently still valid.

Browser developer tools

  • The Network tab shows request headers, cookies and response bodies.
  • The Application or Storage tab shows local storage and session tokens.

Why blurring and pixelating are not enough

Drawing a box over a secret in an image editor feels safe, but it is unreliable:

  • Light blurs and pixelation can sometimes be reversed. Researchers have published tools, such as Depix, that reconstruct pixelated text when the font and size are known — and code is rendered in predictable monospace fonts.
  • Semi-transparent highlights may leave characters readable when contrast is adjusted.
  • Layered formats (some PDF and design-tool exports) can keep the original content under the redaction box.
  • Cropping is fragile. Some phone and editor workflows have kept cropped-out pixels recoverable in the saved file.

The robust approach is simple: the real value should never be in the image at all. Replace it in the text first, then create the image.

How to redact properly: use realistic placeholders

Good placeholders are obviously fake but keep the shape of the original, so the example still teaches something.

# Never share
DATABASE_URL=postgres://admin:S3cr3t!@db-prod-7.internal:5432/app
STRIPE_SECRET_KEY=sk_live_51H8x...
SENTRY_DSN=https://3f2a...@o12345.ingest.sentry.io/678

# Safe to share
DATABASE_URL=postgres://user:password@localhost:5432/app
STRIPE_SECRET_KEY=sk_test_your_key_here
SENTRY_DSN=https://public_key@example.ingest.sentry.io/0

Use values that are reserved for documentation, so they can never point at something real:

Instead of Use Reserved by
Real domains example.com, example.org, example.net, or the .test and .example TLDs RFC 2606
Real IPv4 addresses 192.0.2.0/24, 198.51.100.0/24, 203.0.113.0/24 RFC 5737
Real IPv6 addresses 2001:db8::/32 RFC 3849
Real people Ada Lovelace, ada@example.com Convention
Real keys your_api_key_here, <TOKEN>, sk_test_xxxxxxxx Convention

Keep any prefix that conveys meaning — showing sk_test_ instead of sk_live_ teaches readers to use test keys — but replace everything after it.

For commands, reference environment variables instead of literal values. curl -H "Authorization: Bearer $API_TOKEN" is safe, realistic and copy-pasteable.

A five-step routine before you share anything

  1. Start from safe material. Share .env.example instead of .env, a request made with test-mode keys, and logs from a local run with seed data.
  2. Search the text before rendering it. Look for key, token, secret, password, Bearer, Cookie, @, :// and long random-looking strings.
  3. Replace, don't hide. Swap each value for a placeholder in the text itself.
  4. Read every line of the final image, including the window title, prompt and anything near the edges.
  5. Ask: would I paste this into a public chat room? If not, it does not belong in an image either.

Tools that render pasted text — like Codeshot's environment variables image tool, HTTP request generator, error and log tool and terminal screenshot generator — make step 3 easy: you edit the text directly on the canvas, and the image contains only what you typed. Rendering happens in your browser, so the original never leaves your machine.

What to do if a secret leaks

Assume that anything posted publicly has already been copied. Work through these steps in order:

  1. Revoke or rotate the credential immediately in the provider's dashboard. This is the only step that actually closes the hole.
  2. Check the provider's access logs for use of the credential between the time it was exposed and the time it was revoked.
  3. Remove the image from wherever you posted it and ask anyone who reshared it to do the same.
  4. Tell your security team — or, for an open-source project, the maintainers — so they can follow their incident process.
  5. Fix the root cause. Move secrets into a secrets manager, and add a secret scanner such as gitleaks or GitHub's built-in secret scanning to your repositories and CI.

Make the safe path the easy path

The best defense is having shareable examples ready before you need them:

  • A committed .env.example with placeholder values and a comment for each variable.
  • A collection of sample API requests that use test-mode keys.
  • A seed database with fictional users and orders.
  • A minimal shell prompt you can switch to with one command.

When you want to share something, you start from material that is already safe, and redaction becomes a quick final check rather than a frantic search.

Frequently asked questions

Is it safe to blur an API key in a screenshot?

Not reliably. Light blurs and pixelation can sometimes be reversed, especially for monospace text. Replace the key with a placeholder in the text before creating the image, so the real value is never in the file.

What should I do if I accidentally posted an API key?

Revoke or rotate the key in the provider's dashboard first, then check access logs for misuse, then delete the post. Deleting the post alone is not enough, because automated scanners and other people may already have copied it.

Is a JWT a secret?

Treat it as one. A JWT's payload can be decoded by anyone and often contains personal data, and an unexpired token may still grant access to the account that issued it.

What placeholder domain and IP address should I use in documentation?

Use example.com, example.org or example.net for domains (reserved by RFC 2606) and addresses from 192.0.2.0/24, 198.51.100.0/24 or 203.0.113.0/24 for IPv4 (reserved by RFC 5737).

Should I commit a .env.example file?

Yes. A .env.example with placeholder values documents every variable your project needs, makes onboarding easier and gives you a safe file to share in screenshots and READMEs. Never commit the real .env.

Related guides