Safe Base64 encoding/decoding tool for URL parameters | ZeroTools

This tool is a web application equipped with three dedicated tabs: "Base64 Mutual Conversion", "Text to Base64", and "Base64 to Text", providing processing according to the nature of the data and the purpose of conversion.

The first "Base64 Mutual Conversion" tab receives an already encoded Base64 string as input and performs direct string notation conversion between the standard Base64 format and the URL-Safe Base64 format.

Since this feature does not interpose text encoding (UTF-8) processing, even if the original data is a Base64 string derived from binary such as image or audio rather than text, it executes only the replacement of specified symbols.

The second "Text to Base64" tab is used to simultaneously generate two types of Base64 strings, standard format and URL-Safe format, from plain text (UTF-8) typed into the input area.

This is one way to format the representation when incorporating text data containing multibyte characters into URL parameters or routing of web applications.

In the third "Base64 to Text" tab, the Base64 string of the selected format (standard or URL-Safe) is interpreted and decoded into the original UTF-8 text and output to the screen.

This decoding process configures TextDecoder('utf-8', { fatal: true, ignoreBOM: true }), which throws an error on invalid UTF-8 byte sequences instead of silently substituting them with U+FFFD, while preserving leading BOM marks (U+FEFF).

All these conversion processes and string validations of this tool are executed within the browser's memory using JavaScript, so no mechanism is included to pass data to an external server-side program.

URL-Safe Base64 is a specification that replaces certain alphabet symbols used in standard Base64 (based on RFC 4648) with other symbols that are less likely to cause problems in web browser address bars, URL paths, and query parameters.

The standard Base64 character set includes + (plus) and / (slash), but these have special meanings in specific URL contexts. For instance, + is often interpreted as an encoded space character in the context of application/x-www-form-urlencoded query parameters, while / serves as a delimiter for directory hierarchies in URL paths.

Therefore, if standard Base64 is included in URLs as is, it can cause unintended parsing processing on the server side, resulting in data loss or syntax errors.

To prevent this problem, this tool uses regular expressions during encoding to execute processing that replaces + with - (hyphen) and / with _ (underscore), which are the URL-Safe alphabets.

Furthermore, standard Base64 to URL-Safe conversion removes any trailing = (padding characters) entirely, as their usage and omission depend on the specific protocol being used, and this tool chooses to omit them.

Conversely, in the process of returning a URL-Safe Base64 string to the standard Base64 format, it first replaces all - with + and _ with / in a batch.

Then, it gets the length of the string in character units (code units) and calculates the remainder divided by 4 (length % 4). If this remainder is 2, the missing == is appended to the end of the string, and if the remainder is 3, = is appended, thereby restoring the padding block in 4-character units required by standard Base64 decoders.

Note that Base64 inputs with a length remainder of 1 modulo 4 are structurally invalid and are rejected as errors rather than padded.

The direct conversion feature provided in the "Base64 Mutual Conversion" tab changes data representation between standard Base64 and URL-Safe Base64 at the notation level without intervening UTF-8 text decoding or re-encoding.

Before processing, the input size is evaluated against an upper ceiling of 4,194,304 UTF-16 code units (where any leading or trailing whitespace counts toward this input threshold); inputs exceeding this limit are rejected immediately rather than truncated.

Only outer whitespace characters are trimmed, whereas any internal whitespace such as spaces, tabs, or line breaks will trigger a validation error.

The tool strictly validates the input against the alphabet selected for the conversion direction: standard Base64 requires the A-Z, a-z, 0-9, +, / alphabet, while URL-Safe Base64 requires A-Z, a-z, 0-9, -, _, rejecting characters belonging to the alternate alphabet or external character sets.

Structurally, the validator accepts either properly formed trailing padding (=) or completely unpadded sequences. However, inputs with a length remainder of 1 modulo 4, misplaced interior padding, extraneous padding characters, or mismatched padding syntax are rejected.

In addition, this tool enforces a strict policy verifying that unused final padding bits are set to zero, rejecting non-zero trailing bits (note that RFC 4648 states decoders may reject non-zero padding bits).

Whenever validation fails, no previous successful conversion remains on screen. Standard Base64 output is consistently generated with padding, whereas URL-Safe output is produced without padding.

Switching the direct conversion direction automatically clears both the input and output areas. Because this mode manipulates raw Base64 notation while preserving underlying binary bytes directly, it is ideal for arbitrary binary payloads like image data or token signatures without risking UTF-8 corruption.

All operations run locally in the browser without cryptographic verification.

The encoding process in the "Text to Base64" tab converts entered plain text containing multibyte or international characters into Base64 representations.

Before encoding begins, the input string is checked against an upper limit of 1,048,576 UTF-16 code units (measured as JavaScript string length, where supplementary characters such as emoji count as 2 units, rather than raw bytes or visual graphemes); exceeding inputs are rejected with an error rather than truncated.

Note that numeric capacity limits do not constitute an absolute browser performance guarantee across all devices, and direct file uploads are not supported.

The encoder also validates string integrity by detecting and rejecting unpaired UTF-16 surrogates before passing the valid string to the TextEncoder API to produce a UTF-8 byte array (Uint8Array).

Rather than spreading the entire array at once with String.fromCharCode(...bytes)—which can trigger call stack overflow errors on large payloads—the byte sequence is converted into a binary string in iterative 8,192-byte chunks before applying window.btoa.

Standard Base64 (with padding) and URL-Safe Base64 (unpadded, with - and _) outputs are generated and displayed simultaneously in independent read-only panels.

If encoding fails due to surrogate errors or size limits, any previously displayed output is immediately cleared. Each panel features a clipboard button where success feedback is displayed only after awaiting the asynchronous completion of the Clipboard API; if access is denied or fails, users can manually select and copy the text.

The decode function of the "Base64 to Text" tab restores plain UTF-8 text from an encoded Base64 string. The user selects the input format (standard Base64 or URL-Safe Base64) via the radio interface, and switching between these modes preserves the current input while immediately recomputing the decoded result.

Before decoding, the raw input is evaluated against the 4,194,304 ASCII character limit, where outer whitespace counts toward the cap, and exceeding inputs are rejected.

Outer whitespace is trimmed, but any internal whitespace triggers an immediate validation failure. The string is then validated against strict syntax rules: characters must conform strictly to the chosen format's alphabet without mixing characters from the alternative set; the sequence must not have a length remainder of 1 modulo 4; and trailing padding must be structurally correct, rejecting interior, misplaced, or excessive padding.

Furthermore, this tool strictly rejects non-zero unused final padding bits. Once verified, the data is decoded into raw bytes. To reconstruct text, the tool executes new TextDecoder('utf-8', { fatal: true, ignoreBOM: true }).

Unlike decoders that silently substitute corrupted or non-UTF-8 sequences with the U+FFFD replacement character, this strict implementation throws a fatal decoding error when encountering invalid UTF-8 byte sequences (such as arbitrary binary files, images, or non-UTF-8 encodings like Shift_JIS), ensuring no silent data corruption occurs, while correctly preserving legitimate leading byte-order marks (U+FEFF) and legitimate pre-existing U+FFFD characters.

If an input is invalid, previous decoded outputs are cleared immediately. For arbitrary binary data, users should use the direct notation conversion feature instead of text decoding.

The technologies known as Base64 and URL-Safe Base64 are merely data format conversion (encoding) methods for representing sets of binary data or multibyte characters within the limited character set of ASCII strings, and they are not encryption technologies or security measures for concealing data.

While they serve the purpose of preventing syntax errors caused by conflicts with reserved symbols when passing data as URL parameters, the converted strings themselves are in a state where anyone can easily decode them back to the original data by following the designated reverse conversion procedure.

The implementation of this tool does not include any algorithms for encrypting or decrypting text data, functions for attaching digital signatures using hashes to prevent data tampering, or functions for verifying the validity of authentication tokens like JSON Web Tokens (JWT).

Therefore, a system design that simply converts sensitive data that must be kept secret from third parties, such as passwords, session keys, or Personally Identifiable Information (PII), into URL-Safe Base64 using this tool and attaches it to URL parameters is highly inappropriate.

If proof of data confidentiality or integrity is required, a clear boundary is needed, such as using a backend system or a dedicated encryption library to perform appropriate encryption processing and signing in advance, and then applying Base64 conversion only to the resulting byte array for the purpose of matching notation rules.

Also, since data compression features and file I/O are not supported, operation based on an understanding of the specifications is necessary.