Text to Base64

Base64 turns arbitrary bytes into a safe ASCII alphabet of letters, digits, plus, slash, and equals padding so text can travel through JSON, forms, email headers, and configuration files without corruption. This capability focuses on the everyday job people type into search: convert plain text to Base64, or turn a Base64 string back into readable UTF-8, with a single mode field and classic standard padding. Encoding is deterministic UTF-8 then RFC 4648; decoding rejects illegal alphabet characters, broken padding, and non-UTF-8 payloads with a clear invalid input error instead of silent garbage.

Encode text to standard Base64 with padding

The engine interprets the string as Unicode text, serializes it to UTF-8 bytes, and maps those bytes to the sixty-four character alphabet A through Z, a through z, zero through nine, plus, and slash. Empty strings are valid: they encode to an empty Base64 result with zero bytes. Multilingual text, emoji, and punctuation all round-trip because the path is full UTF-8, not a Latin-1 shortcut. Identical inputs always produce identical outputs because the algorithm is pure arithmetic with no network, no random salt, and no wall clock. Send a JSON body with the required string field text set to the plain message you want to protect for transport, and leave mode at its default encode or set mode to encode explicitly. When the byte length is not a multiple of three, one or two equals signs are appended so every output is a multiple of four characters—this is standard padding, the form most HTTP APIs, data URLs for text snippets, and classic tutorials expect. Optional aliases input, value, and s are accepted for the same field when you generate clients from older form names. The response always includes result with the Base64 string, mode equal to encode, padding equal to standard, and bytes equal to the UTF-8 length before encoding so you can assert payload size in tests. Use this path whenever you need a paste-safe representation of a secret fragment, a config token, or a small JSON snippet that must survive a text-only channel.

Decode Base64 back to text and handle invalid input

Set mode to decode and put a standard Base64 string in text. Successful decode returns result as the recovered string, mode decode, padding standard, and bytes as the decoded UTF-8 length. Prefer this capability when your search intent is literally text to base64 or base64 to text for human-readable content; binary image data URIs belong to image-oriented tools, and URL-safe cookies belong to specialized encoders. Leading and trailing spaces, tabs, and newlines are stripped so multi-line pastes still work, but any other character outside the standard alphabet causes an immediate invalid_input failure—the engine does not silently remap URL-safe minus and underscore variants, because that would blur the product promise of standard padding and alphabet. Padding equals signs may be present or omitted when the remainder is legal; more than two pads, pads in the middle, or a length whose modulo four is one are rejected with an explicit message so clients can fix the payload. After alphabet validation, the bytes are decoded as UTF-8 with a fatal decoder: if the payload is not valid Unicode text, you get invalid_input instead of replacement characters that would corrupt downstream displays. Validation failures are not charged on the prepaid API, so probing a suspicious token is cheap for operators and safe for end users.

API usage, pricing, workflows, and practical limits

Use the prepaid KIT API when a backend, serverless function, or SDK needs the same encode or decode step under balance at $0.002 per successful item; failed validation never consumes balance after the engine rejects the request. Pair this endpoint with URL percent-encoding tools when a string must survive both Base64 and query-string rules, but keep the steps separate so each landing page matches a single search intent.