FunnyTools for your work
Developer Tools for JSON, Encoding, UUIDs, Timestamps, and Markdown
Development and debugging often involve small data tasks: format JSON, encode a URL, decode Base64, generate a UUID, convert timestamps, move between CSV and JSON, preview Markdown, or create a QR code for testing. This page collects lightweight FunnyTools utilities for those checks. Use them for examples, test data, and non-sensitive content; secrets, personal data, and confidential company data need approved security workflows.
Common needs
- Small data conversions should not require a heavy IDE or service.
- Debugging often needs readable JSON, timestamps, and encoded strings.
- Test data and password generation must avoid exposing real secrets.
Recommended tools
Suggested workflow
- Paste only test or anonymized data, not real tokens, passwords, or personal data.
- Format JSON or convert timestamps, then return to code to verify field meaning.
- After CSV/JSON conversion, spot-check field names, empty values, and special characters.
Audience editorial review:
Tool selection and delivery criteria for Developer Tools
This section works from the pageβs own scenario β turning a raw API response into a shareable debugging sample β and the FAQβs warning that formatting tools change layout, not meaning.
Reproduce the two-step sanitization the scenario requires, in the stated order
The pageβs scenario is explicit that "make the structure readable" and "confirm nothing sensitive remains" are two separate steps, not one β the formatter only makes JSON structure readable and does not detect or mask any field automatically. Test this on a real but low-stakes JSON fragment: run it through json-formatter first, then read through the formatted output by eye specifically looking for emails, tokens, or user IDs, and manually replace anything real with an obviously fake placeholder. Skipping straight from formatting to sharing is the mistake this two-step sequence is meant to prevent.
Confirm seconds versus milliseconds before writing a timestamp into a bug report
The scenario recommends converting one or two representative Unix timestamps with timestamp-converter specifically to confirm whether the value is in seconds or milliseconds before writing the converted time into a report. Self-test: a 10-digit Unix value is almost always seconds, and a 13-digit value is almost always milliseconds β feeding a millisecond value into a converter expecting seconds produces a date far in the future or the distant past, which is itself the tell that the wrong unit was assumed.
Self-check what json-formatter does not do, and where real secrets belong
The FAQ states plainly that JSON formatting does not fix data meaning β it only helps readability and basic structure, while field meaning, types, and business rules still need review. It also states that real API keys should not be pasted here at all, even though the tool is browser-oriented, because production secrets belong in approved secure tooling, not a general-purpose formatter. Self-test: if a JSON fragment about to be pasted contains anything that would matter if leaked, redact it before pasting, not after.
Audience workflow acceptance
- Ran a JSON fragment through the formatter, then manually scanned the output for real emails, tokens, or IDs and replaced them with placeholders β as two separate steps, not one.
- Identified whether a Unix timestamp was in seconds (10 digits) or milliseconds (13 digits) before converting and citing it in a report.
- Re-validated edited JSON as syntactically correct (no dropped brackets or commas) after manually redacting sensitive values.
- Confirmed no real API keys, passwords, or production secrets were pasted into any formatting tool, regardless of how it processes data.
Step-by-step scenario
Workflow: Turn a raw API response into a clean, shareable debugging sample
Debugging often means pasting an entire raw response to a teammate, which can carry real user data along with it. This workflow treats "make the structure readable" and "confirm nothing sensitive remains" as two separate steps, not one.
- Copy only the JSON fragment relevant to the bug, and scan it by eye before pasting it into json-formatter, since the formatter only makes structure readable and does not detect or mask any field automatically.
- After formatting, manually replace any real email addresses, tokens, user IDs, or names you can see with obviously fake placeholders; this step has to be done by hand, since the tool has no awareness of which field is sensitive.
- If the response contains Unix timestamps that are hard to read, convert one or two representative values with timestamp-converter to confirm whether you are reading seconds or milliseconds, then write the converted time into the bug report so the discussion does not drift on a wrong timeline.
- Run the edited text through the formatter once more to confirm it is still valid JSON and that manual edits did not drop a bracket or comma, then share the cleaned sample.
Verification before useοΌBefore sharing, read through the sample once more to confirm nothing looks like real user data, and that the sample alone cannot be used to re-identify a specific user or account.
Related categories
FAQ
- Can I paste real API keys?
- No. Even when a tool is browser-oriented, real secrets should stay in approved secure tooling.
- Does JSON formatting fix data meaning?
- No. It helps readability and basic structure; field meaning, types, and business rules still need review.
- What should I watch for with timestamps?
- Check seconds vs milliseconds, time zone, daylight saving behavior, and display format.
- Can generated passwords be used for real accounts?
- It can help generate strong passwords, but use a password manager for storage and adjust to the target system rules.