How to Redact and Review Sensitive JSON

DevToolKit JSON Formatter parses and pretty-prints the textarea content in the browser; the formatting operation does not upload that JSON to a conversion server. That removes one transfer from the workflow, but it is not a promise that sensitive data cannot be exposed.

The input and result remain in application memory while the component is in use and appear in the rendered tab. Browser extensions with relevant access, screen-sharing software, recordings, screenshots, clipboard tools, and onlookers are separate exposure paths that local formatting does not control.

Use invented values that preserve type and shape: a placeholder string for a token, a reserved example address for an email, and an obviously fictional identifier for an account. Keep arrays, nesting, booleans, and null values only when they matter to the review.

Do not assume staging credentials are harmless. They may still grant access to a test environment or reveal real employee, customer, tenant, or infrastructure details. Production data should not be the default source for a formatting example.

An expired token can still expose issuer, subject, audience, account identifiers, roles, timestamps, and other claims. Expiration changes whether a correctly configured verifier should accept the token; it does not erase the encoded content or make the token appropriate for a ticket or screen share.

Example before redaction: {"access_token":"eyJ-live-access","refresh_token":"refresh-live-4821","profile":{"email":"person@example.com","phone":"+39-555-0100","account_id":"acct_8142"},"cookies":{"session":"session-live-93"},"integration":{"credentials":{"client_id":"client_77","client_secret":"secret-live-42"}}}

Example after redaction: {"access_token":"REDACTED_ACCESS_TOKEN","refresh_token":"REDACTED_REFRESH_TOKEN","profile":{"email":"user@example.invalid","phone":"REDACTED_PHONE","account_id":"ACCOUNT_EXAMPLE"},"cookies":{"session":"REDACTED_COOKIE"},"integration":{"credentials":{"client_id":"CLIENT_EXAMPLE","client_secret":"REDACTED_SECRET"}}}

Review nested objects instead of stopping after the obvious top-level fields. Access tokens, refresh tokens, email addresses, phone numbers, account IDs, cookies, client secrets, and other nested credentials can coexist in one response. Preserve the structure needed for the discussion while replacing the sensitive values.

A complete JWT contains header, payload, and signature segments and may function as a bearer credential. Do not paste a live token merely to inspect its structure. A decoded payload is not the complete credential, but it can still disclose identities, permissions, tenant data, or operational details.

DevToolKit JWT Decoder decodes the header and payload but does not cryptographically verify the signature. A readable payload does not prove who issued the token, whether it was modified, or whether an application should accept it.

Signature verification belongs in a trusted verification flow with the correct issuer key or secret and the application's expected validation rules. That flow is outside this decoder; it is not necessarily limited to a server, and formatting decoded JSON is not a substitute for it.

Base64 is reversible encoding, not encryption or protection. Base64-encoded text may contain another JSON document, a token, or a secret that becomes immediately readable after decoding. Decode only what the review requires, then redact the decoded values before sharing them.

URL-encoded values can likewise reveal readable identifiers or credentials after decoding. Treat encoded fields according to their decoded meaning, and do not assume punctuation changes such as percent escapes have removed sensitivity.

Clipboard history features or third-party clipboard managers may retain copied content when they are enabled. Before manually copying sensitive text, check the controls that apply to the current device and work profile; after the task, remove retained entries where the configured tool provides that option.

Confirm whether a display, meeting, remote-support session, stream, screenshot utility, or screen recorder is active before showing the tab. Closing or obscuring unrelated sensitive tabs does not sanitize the JSON currently visible in the formatter.

Formatted output is easier for reviewers to scan, which also makes exposed names, IDs, and credentials easier to notice and reuse. Review the redacted result once more before placing any part of it in documentation, chat, issue trackers, or source control.

First, replace the source with synthetic data whenever the real values are unnecessary. Second, redact sensitive values at every nesting level while preserving only the structure needed for the discussion. Third, inspect decoded JWT, Base64, or URL-encoded content for values that were not visible in the outer JSON.

Fourth, confirm that the intended screen, recording, and clipboard conditions are understood for the current device. Fifth, review the rendered result for remaining credentials, identifiers, cookies, and personal data. Finally, share only the smallest useful excerpt and use a trusted verification flow for authenticity or signature decisions that this formatter and decoder do not perform.