About

Base64 encoding is the standard method for transmitting binary or text data through channels that only support ASCII. Database migration scripts, API payloads, and CI/CD pipeline artifacts frequently store SQL statements as Base64 strings. Decoding these manually with command-line tools introduces risk: incorrect character encoding (especially with UTF-8 multi-byte sequences like ñ or ü) silently corrupts your queries. A malformed INSERT statement can write garbage to production tables. This tool decodes both standard (RFC 4648 §4) and URL-safe (RFC 4648 §5) Base64, handles missing padding characters, and applies proper UTF-8 decoding via the TextDecoder API. The optional SQL formatter identifies clause boundaries and indents subqueries for readability.

Limitations: this tool does not validate SQL syntax or execute queries. It performs a faithful byte-level decode and presents the result. If the Base64 input encodes binary data (not text), the output will appear as garbled characters. For inputs exceeding 5 MB, performance may degrade in older browsers. Pro tip: if your Base64 string originates from a URL query parameter, it is likely URL-safe encoded - the tool auto-detects and handles the - and _ character substitutions.

Formulas

Base64 encoding converts every group of 3 bytes (24 bits) into 4 ASCII characters selected from an alphabet of 64 symbols. The encoded length is therefore predictable:

L_encoded = 4 ⋅ ceil(L_bytes3)

Where L_bytes = original byte count of the SQL string. The = padding character fills incomplete groups. URL-safe Base64 substitutes + → - and / → _, and may omit padding. The decode reverses this mapping:

decode(s) = TextDecoder(atob(normalize(s)))

Where normalize strips whitespace, restores URL-safe substitutions, and re-pads to a multiple of 4. Each Base64 character maps to a 6-bit value (since 2⁶ = 64). The alphabet index is: A - Z = 0 - 25, a - z = 26 - 51, 0 - 9 = 52 - 61, + = 62, / = 63.

Reference Data

SQL Keyword	Category	Standard	Formatting Rule Applied
SELECT	DQL	SQL-92	Newline before, no indent
FROM	Clause	SQL-92	Newline before, indent 1 level
WHERE	Clause	SQL-92	Newline before, indent 1 level
AND / OR	Logical	SQL-92	Newline before, indent 2 levels
JOIN / LEFT JOIN	Clause	SQL-92	Newline before, indent 1 level
ON	Condition	SQL-92	Newline before, indent 2 levels
INSERT INTO	DML	SQL-92	Newline before, no indent
VALUES	Clause	SQL-92	Newline before, indent 1 level
UPDATE	DML	SQL-92	Newline before, no indent
SET	Clause	SQL-92	Newline before, indent 1 level
DELETE FROM	DML	SQL-92	Newline before, no indent
CREATE TABLE	DDL	SQL-92	Newline before, no indent
ALTER TABLE	DDL	SQL-92	Newline before, no indent
DROP TABLE	DDL	SQL-92	Newline before, no indent
GROUP BY	Clause	SQL-92	Newline before, indent 1 level
ORDER BY	Clause	SQL-92	Newline before, indent 1 level
HAVING	Clause	SQL-92	Newline before, indent 1 level
LIMIT	Clause	MySQL/PG	Newline before, indent 1 level
OFFSET	Clause	MySQL/PG	Newline before, indent 1 level
UNION	Set Op	SQL-92	Newline before and after, no indent
WITH (CTE)	DQL	SQL:1999	Newline before, no indent
BEGIN / COMMIT	TCL	SQL-92	Newline before, no indent
CASE	Expression	SQL-92	Newline before, indent 1 level
WHEN / THEN	Expression	SQL-92	Newline before, indent 2 levels
END	Expression	SQL-92	Newline before, matches CASE indent

Frequently Asked Questions

URL-safe Base64 (RFC 4648 §5) replaces + with - and / with _, and often omits the trailing = padding characters. The converter auto-detects these substitutions by scanning for - or _ characters. It normalizes the input back to standard Base64 before decoding: restoring the original characters and appending padding until the string length is a multiple of 4.

The converter decodes all bytes faithfully using the TextDecoder API with UTF-8 encoding. If the underlying data is binary (e.g., a compressed archive or image), the output will contain replacement characters (U+FFFD) or garbled text. The tool displays a warning when no SQL keywords are detected in the decoded output, indicating the source data is likely not a SQL statement.

No. The formatter is purely cosmetic. It inserts whitespace (newlines and spaces) around recognized SQL keywords for readability. It does not parse the SQL AST, reorder clauses, or alter string literals. Content inside single-quoted string literals is preserved exactly as decoded. The raw (unformatted) output is always available via the format toggle.

Standard Base64 uses only the characters A - Z, a - z, 0 - 9, +, /, and =. If the input contains other characters (e.g., #, %, or newline-encoded %0A), it is not valid Base64. Common causes: the string was URL-encoded on top of Base64 (double encoding), or it was truncated during copy-paste. Verify the source and ensure you copied the complete string.

Yes. The decoder outputs the full decoded text regardless of how many SQL statements it contains. The formatter recognizes statement-level keywords like BEGIN, COMMIT, CREATE TABLE, and treats semicolons as statement terminators, adding a blank line after each ; for visual separation. There is no limit on the number of statements.

The converter processes input in-browser using JavaScript's native atob function. Practical limits depend on available memory. Inputs up to 5 MB of Base64 text (decoding to approximately 3.75 MB of SQL, since Base64 inflates size by a factor of 43) work reliably. Beyond that, some browsers may become unresponsive.