Encode or decode text with 17 explicit byte, web, message, and legacy representations, or turn a verified PNG, JPEG, GIF, or WebP file into Base64. Each mode identifies its byte or text profile, validates bounded input, tests round trips where defined, and reports lossy or implementation-specific mappings instead of claiming universal interoperability.
Continue with a related workflow or open the next tool that usually follows this task.
This workflow uses the Cipher Learning Workbench to make XOR byte mechanics visible. You will reproduce a known vector, switch between Hex and Base64, reverse it with the same key, and document why the exercise must never be presented as protection for real secrets.
OpenRelated toolStrictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
OpenRelated toolInspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
OpenRelated toolConvert one IDN between Unicode and Punycode with strict validation and label review.
OpenChoose the exact representation from the grouped menu, then select Encode or Decode when the mode supports both directions.
Set the variant, byte order, entity style, image output form, or UUEncode metadata before entering source data.
Remove secrets and personal data before sharing screenshots or results; local processing prevents an upload by this tool but does not make the output confidential.
Paste a bounded text sample or select one PNG, JPEG, GIF, or WebP file no larger than 2,097,152 bytes.
Run the Worker and review every normalization notice, byte count, character count, decoded filename, and round-trip or image-signature result.
Copy or download the full result, then test it with the actual receiving system and preserve the original until interoperability is confirmed.
Compare binary, hexadecimal, Base32, Base58, Base62, ASCII85, or Z85 output while preserving the exact alphabet and padding contract needed by a receiving API.
Encode HTML or XML text characters with a known entity policy, or decode references for review without executing the resulting markup or script.
Convert a Unicode hostname through strict UTS #46 rules and compare the ASCII label with the Unicode display form before editing DNS or application allowlists.
Prepare quoted-printable mail text, International Morse, Unicode escapes, or a legacy UUEncode block while keeping normalization and metadata visible.
Turn one signature-checked raster image into raw Base64 or a data URI for a small fixture, CSS test, email template, or API payload, then verify destination size and CSP limits.
Base32, Base58, Base62, Base85, hexadecimal, and Base64 are reversible representations. Anyone who receives the output can recover the source; use authenticated encryption when confidentiality or tamper detection is required.
A decoder needs the same alphabet, byte order, padding policy, text charset, and container convention as the producer. Base62 and custom emoji representations have no universal interchange alphabet in this workbench.
Latin-1 is not Windows-1252, UTF-16 byte order is not auto-detected without a BOM, and arbitrary bytes are not necessarily valid UTF-8 text. Choose a byte-oriented file workflow for non-text payloads.
A successful round trip proves that this implementation can reverse the selected representation. It does not prove another library uses the same Base62 alphabet, HTML entity set, IDNA profile, UUEncode metadata rules, or line-ending convention.
Data URIs increase text size, can exceed browser or platform limits, and may interact with Content Security Policy. A verified image signature does not establish that image content is safe, appropriate, licensed, or free of metadata.
The UTF-8 bytes for the text are shown as complete octets, then decoded again before the result is accepted.
Hi01001000 01101001Base32 uses the RFC 4648 alphabet and canonical padding while accepting a clearly reported lowercase or unpadded input on decode.
fooMZXW6===Strict UTS #46 processing converts the Unicode domain and rejects invalid labels instead of falling back to a best-effort string transformation.
bücher.examplexn--bcher-kva.exampleNamed HTML entities are limited to a documented common set; hexadecimal numeric references are available when an exact scalar value is preferable.
5 < 7 & ©5 < 7 & ©The UUEncode header carries a validated basename and octal permission, while the payload is formed from UTF-8 bytes in bounded lines.
Hello with filename data.txt and permission 644begin 644 data.txt
%2&5L;&\`
`
endThe worker verifies both the declared MIME type and the PNG, JPEG, GIF, or WebP byte structure before producing raw Base64 or a data URI.
A locally selected PNG filedata:image/png;base64,iVBORw0KGgo...Text input is validated as well-formed Unicode and measured as both code points and UTF-8 bytes before conversion. ASCII, binary, hexadecimal, Base32, Base58, Base62, ASCII85, Z85, Latin-1 hexadecimal, and UTF-16 hexadecimal use explicit byte-level algorithms rather than coercing JavaScript strings through platform-dependent shortcuts.
RFC 4648 Base32 checks alphabet, padding, and zero trailing bits. Bitcoin Base58 and the documented 0-9/A-Z/a-z Base62 alphabet preserve leading zero bytes, but their repeated radix conversion is resource-intensive, so both encoded and decoded paths receive an 8,192-byte-specific bound before expensive work.
HTML mode recognizes a bounded common named-entity table plus valid numeric references; XML mode follows the five predefined XML entities and XML 1.0 character ranges. Unicode escapes reject unpaired surrogates, Punycode delegates to strict UTS #46 IDN validation, and no mode evaluates decoded source as markup or JavaScript.
Quoted-printable encodes UTF-8 with 76-character physical lines, Morse declares uppercase normalization and its supported alphabet, the emoji form is a documented custom hexadecimal token map, and UUEncode validates filename, octal permission, line lengths, terminator, and end marker. Latin-1 and UTF-16 choices remain explicit rather than guessed.
A dedicated Worker performs each conversion with a 15-second timeout and memory estimate. After text conversion, the inverse codec runs and the recovered value is compared under only the documented normalization rules. Image mode checks claimed MIME, signature, and basic PNG, JPEG, GIF, or WebP structure. Analytics receives mode, safe option names, timing, byte counts, and notice counts, never source or output content.
No. Encoding changes representation, not access control. Base32, Base58, Base62, Base85, hexadecimal, entity references, Unicode escapes, quoted-printable, and UUEncode are reversible. Do not paste secrets merely because processing is local, and use a reviewed encryption system for confidentiality.
For text modes, the workbench immediately performs the inverse operation with the same explicit options and compares the recovered value. Morse and quoted-printable use documented case or line-ending normalization. A pass detects many implementation and option mistakes, but cannot certify interoperability with an unknown external producer.
Base58 uses the Bitcoin alphabet. Base62 uses 0-9, A-Z, then a-z and is explicitly marked non-standard because other systems choose different orders. ASCII85 requires Adobe delimiters; Z85 requires complete four-byte or five-character blocks.
No. Latin-1 mode accepts only characters U+0000 through U+00FF and is not Windows-1252. UTF-16 mode requires an explicit little- or big-endian choice and intentionally omits a BOM. For unknown data, inspect the source specification or use the Charset Detector before converting.
The selected file is read by a dedicated browser Worker. Its claimed type is checked against PNG, JPEG, GIF, or WebP signatures and basic container structure, with a 2 MiB input cap. The file and generated Base64 are not uploaded by this tool, but the result can still reveal every image byte when shared.
Text is limited to 262,144 UTF-8 bytes and 524,288 Unicode code points, with a smaller 8,192-byte cap for quadratic Base58 and Base62 operations. Text output is limited to 2,097,152 bytes, images to 2,097,152 source bytes, and image Base64 output to 3,145,728 bytes. A Worker timeout and memory guard add browser-level protection.
Maintained and tested by SimpleWebUtilsReviewed
Method: The review loaded the unmodified “Verify RFC 4648 Base32 for a UTF-8 text field” sample into Encoding Workbench. We exercised the path from “Write the receiver contract before converting” to “Test the actual receiver in both directions”, checked the displayed or downloaded result against the example, and separately examined “Choosing from the shortest output” and “Assuming every Base62 or Base85 is identical”.
Expected result: UTF-8 “café!” encoded to the canonical padded Base32 vector MNQWNQ5JEE====== and decoded back to the same bytes under the stated RFC 4648 contract.
Open the tested workflowUse these focused guides when you need a practical workflow before opening the tool.
This workflow uses the Cipher Learning Workbench to make XOR byte mechanics visible. You will reproduce a known vector, switch between Hex and Base64, reverse it with the same key, and document why the exercise must never be presented as protection for real secrets.
Workflow guideUse this workflow when an API, database field, DNS label, email body, configuration file, or legacy transport asks for Base32, Base58, Base62, Base85, hexadecimal, entities, Punycode, quoted-printable, UTF-16, or UUEncode but does not fully describe the variant.
Workflow guideThis workflow turns a folder of product, proof, or portfolio images into a reviewed sharing set: preserve the masters, choose text or logo for a clear purpose, test contrast and rotated placement across representative aspect ratios, process only supported static files, and verify format, metadata, naming, and visual quality after download.
Continue with another maintained workflow
Strictly encode UTF-8 and decode Base64, Base64URL, data URIs, and binary byte output locally.
Inspect BOM, strict UTF-8, Unicode structure, ASCII compatibility, and binary clues from local file bytes.
Convert one IDN between Unicode and Punycode with strict validation and label review.
Normalize Unicode with code-point evidence and explicit compatibility-loss warnings.
Encode or decode exact URL components, full URLs, and form values locally.