Developer Cheatsheet for JSON, Regex, SQL, URLs, and Base64

Overview

Data-handling problems often look different but follow the same pattern: identify the format, preserve the original value, make one controlled transformation, validate the result, and test it in the environment where it will be used. A formatter can make data readable, but it does not prove that the data is correct. An encoder can change representation, but it does not make sensitive data safe. A regular expression can match a shape, but it cannot replace business validation.

Keep those distinctions in mind as you use this reference. Work on a copy of the input, avoid placing secrets or personal data into third-party tools, and record whether a value is being parsed, validated, escaped, encoded, decoded, or merely formatted. Those operations are related, but they solve different problems.

Quick reference

• JSON: use strict syntax, double-quoted property names, valid values, and no trailing commas.
• Regex: define the accepted input before writing the pattern, then test valid, invalid, and boundary cases.
• SQL: parameterize values, qualify columns in joins, and inspect the query plan when performance matters.
• URLs: encode individual components according to their role rather than encoding an entire URL indiscriminately.
• Base64: treat it as a representation for bytes, not encryption or access control.

Step-by-step workflow

1. Identify the value and its boundary

Start by asking what you actually have. Is it a complete JSON document, a JSON string nested inside another field, a URL query parameter, a SQL fragment, or a Base64 representation of bytes? Copy the exact input into a scratch file and label its source, expected format, and intended destination.

Boundaries matter. A URL contains a scheme, host, path, query, and fragment. A SQL statement contains syntax and data values. JSON may contain escaped strings that look like another format. Treating the whole value as one undifferentiated string is a common cause of double encoding and invalid parsing.

2. Format and parse JSON before editing it

A JSON formatter is useful for readability, but parsing is the more important test. A minimal valid object looks like this:

{"name":"Ada","active":true,"roles":["editor"]}

Common JSON errors include single-quoted keys, comments, trailing commas, unescaped control characters, and values such as undefined or NaN, which are not standard JSON values. If an API returns a JSON string inside a response field, parse the outer document first and then parse the nested string only when the contract requires it.

For configuration work, also decide whether JSON is the correct format. JSON is strict and broadly supported; YAML can be more expressive for human-maintained configuration but introduces its own syntax rules. See JSON vs YAML: When to Use Each for Config Files and APIs before converting a working file.

3. Build and test regex patterns from examples

Write three or more examples before writing the pattern: an ordinary valid value, a clearly invalid value, and an edge case. For example, a simple pattern for a lowercase hexadecimal color without an alpha channel is:

^#[0-9a-f]{6}$

The anchors require the entire input to match. Without them, a search operation might find a valid-looking substring inside a larger invalid value. In application code, distinguish between searching for a match and validating the complete input. Also check how the target language handles escaping; a backslash may need escaping in both the regular expression and the source-code string.

Do not use one large regex to enforce every business rule. A pattern can check shape, while ordinary code can check length, uniqueness, permissions, or whether a date is valid in a particular calendar context. For additional examples and debugging advice, use The Practical Regex Cheat Sheet.

4. Write SQL with parameters and explicit intent

Keep SQL structure separate from user-supplied values. Prefer a parameterized query such as:

SELECT id, email
FROM users
WHERE status = ?
  AND created_at > ?;

The placeholder syntax varies by database driver, so follow the interface used by your application. Do not construct the statement by concatenating request values into the SQL string. When joining tables, qualify columns with aliases, select only the columns needed, and add an explicit ordering when result order matters:

SELECT u.id, o.total
FROM users AS u
JOIN orders AS o ON o.user_id = u.id
WHERE u.id = ?
ORDER BY o.created_at DESC;

Test queries with empty results, duplicate relationships, null values, and unexpectedly large inputs. A query that returns the right rows in a small development dataset may still need indexes, pagination, or a different access pattern in production.

5. Encode URL components, not guesses

URL encoding is context-dependent. A query parameter value such as red & blue must be encoded before it is placed into a query string, producing a representation such as red%20%26%20blue. Use a URL builder or the standard URL API in your language rather than manually replacing a few characters.

Keep the URL structure separate from its values. If you encode an entire URL and then insert it as a URL, you may encode separators such as :, /, and ? that the parser needs. After constructing the URL, parse it again and verify the scheme, host, path, query keys, and fragment.

6. Decode Base64 only when the context supports it

Base64 converts bytes into text characters so the data can travel through systems that expect text. It does not provide confidentiality, integrity, or authentication. A typical value may end with padding characters such as =, although some variants omit padding or use different URL-safe characters.

Before decoding, identify the expected variant and character encoding. After decoding, check whether the result is text, JSON, an image, a certificate, or another binary format. Never treat decoded content as trusted merely because it was successfully decoded. For a deeper explanation of appropriate and inappropriate uses, read Base64 Encoding Explained.

Tools and handoffs

Use tools according to the job rather than choosing one universal utility. A JSON formatter or parser is appropriate for structure and syntax. A regex tester helps you compare patterns against a visible test set. A SQL formatter improves readability, while a database client or test suite is needed to verify actual behavior. A URL encoder should operate on a selected component, and a Base64 tool should make the chosen variant clear.

For sensitive inputs, prefer local command-line utilities, an editor extension, or a small script that runs in your controlled environment. Browser-based coding tools can be convenient for harmless examples, but do not paste credentials, access tokens, private customer records, production dumps, or proprietary source code into an unapproved service.

Document the handoff between tools. Record the input format, transformation applied, expected output, and the next system that will consume it. For example: parse JSON, extract the callback URL, encode the query value, send it through the HTTP client, then inspect the server's parsed parameters. This is easier to troubleshoot than a note that simply says encoded the payload.

When a tool produces a result that will become application code, move the example into a repeatable test. Manual formatting is useful during investigation; automated tests protect the behavior after the investigation is over.

Quality checks

• Round trip: where appropriate, encode then decode, serialize then parse, or build then parse a URL. The result should preserve the intended value.
• Negative cases: test malformed JSON, incomplete Base64, unmatched regex input, null database values, empty query results, and incorrectly encoded URL characters.
• Type checks: confirm that a number was not turned into a string, a boolean was not treated as text, and a decoded byte sequence is interpreted with the correct character encoding.
• Boundary checks: test empty strings, maximum expected lengths, Unicode characters, whitespace, repeated separators, and reserved URL characters.
• Security checks: use SQL parameters, validate inputs at the application boundary, avoid logging secrets, and remember that encoding is not encryption.
• Environment checks: run the final example with the same language, database driver, URL parser, or protocol version used by the target system.

Keep a small regression set for every recurring transformation. Five carefully chosen examples are often more useful than a long unreviewed list. Include the expected result and the reason each case matters.

When to revisit

Return to this cheatsheet when a platform, database driver, language runtime, or internal data contract changes. Recheck examples when a URL parser is replaced, a regex is moved into a different programming language, a query gains a new join, or an API changes a field from a string to an object. Tool interfaces and supported options can change as well, so verify the current documentation before relying on a command or option in automation.

Make updates practical: review the examples against the current runtime, replace any deprecated syntax, add one regression case for the change, and remove advice that no longer matches your systems. For a broader debugging process, connect this reference with The Practical JavaScript Debugging Workflow. If you use AI to draft a query or pattern, treat the output as a starting point and verify it with tests; the guidance in Prompt Engineering for Developers can help structure that review.

Next action: choose one recurring task from your workflow, save a clean input and expected output, add a malformed case, and automate the round-trip check. That small reference set will give your team a dependable starting point the next time JSON, regex, SQL, URLs, or Base64 data needs attention.