Developer · THE NO-PANIC PLAN
Encode UTF-8 text for an API that requires standard Base64
Use this workflow only when the receiving API contract explicitly requires standard RFC 4648 Base64 for a UTF-8 text value. Nirmion's Base64 Encoder uses the standard `A-Z`, `a-z`, `0-9`, `+`, `/` alphabet and padding, and runs in the browser; its paired decoder accepts standard Base64 that decodes to valid UTF-8 text. Base64 changes representation, not confidentiality: do not encode passwords or secrets to hide them. Base64url is a distinct alphabet and is not interchangeable unless the receiving protocol says so. For binary files or arbitrary byte sequences, use the API's specified byte-safe library rather than a text-only converter.
MISSION Encode an exact UTF-8 text value using standard Base64 for an API field that explicitly requires that representation, then verify the decoded value and transport handling.
Encode a non-sensitive UTF-8 test valueTHE REAL-WORLD BIT
What happens outside this browser tab?
Confirm the API's required alphabet, padding, line-wrap, and text encoding; preserve the exact UTF-8 input; encode with the browser-local standard Base64 tool; round-trip through a UTF-8 decoder and compare exact text; then submit using the API's required transport encoding and validate the receiving service in a non-production environment.
YOUR CHECKLIST, WITH FEWER DRAMATIC SIGHES
One step at a time.
Follow the order below. If a step names a Nirmion tool, its link is right there with it.
- 01
Read the receiver contract and confirm standard Base64 is required
Check the API field description, protocol specification, and a known-good example. Confirm that the payload is text encoded as UTF-8 and that the server expects the standard Base64 alphabet, its padding behavior, and any line-break rules. RFC 4648 distinguishes the standard alphabet from Base64url, which substitutes characters and may have different padding conventions. If the endpoint expects raw text, bytes, a data URL, or Base64url, stop and follow that contract instead; a syntactically valid Base64 string can still be the wrong value for the field. Record the API version and a non-sensitive test fixture to make the result reproducible. (Sources 1, 2, 3)
- 02
Preserve the exact text that must be encoded
Copy the exact approved text into a temporary working value and decide whether spaces, line endings, tabs, or Unicode characters are significant to the receiver. Do not trim, normalize, change capitalization, or add a newline unless the API contract requires it; those changes alter the bytes and therefore the encoded result. Nirmion's encoder converts the JavaScript string into UTF-8 bytes before applying Base64, which handles non-ASCII text differently from APIs that treat strings as legacy binary strings. Use a harmless sample for initial checks and keep personal data or secrets out of the tool unless your data policy explicitly permits their processing. (Sources 2, 3)
- 03
Encode the text with the browser-local standard encoder
Use Base64 Encoder (Nirmion tool 150) to convert the confirmed UTF-8 text to standard Base64. The tool processes the text in the browser and emits the standard alphabet; it does not select Base64url, create a data URL prefix, encrypt the content, or make a secret safe to share. Preserve the result exactly, including required trailing `=` padding. Do not replace `+` with a space or edit `/` or padding by hand. If the surrounding transport is a URL or form field, apply that transport's own encoding to the Base64 value instead of silently changing the Base64 alphabet. (Sources 1, 2, 4)
- 04
Decode a copy and compare the original text
Use Base64 Decoder (Nirmion tool 151) on a copy of the result and compare the decoded text with the original character for character, including spaces, line endings, and non-ASCII characters. The paired decoder accepts standard Base64 that produces valid UTF-8 text; a failure can mean the value is malformed, is a different Base64 variant, or represents binary data rather than text. Do not repair output by guessing at padding or removing characters until it decodes. If the API contract permits multiple encodings or binary content, use its official SDK or a byte-oriented implementation and validate with its own examples. (Sources 1, 2, 4)
- 05
Test the receiving API and protect the resulting value
Send a harmless fixture to a non-production endpoint using the API's documented JSON, header, URL, or form field rules. Confirm the service decodes the intended UTF-8 value and handles padding, Unicode, and transport-special characters correctly. Compare the server-side result with the approved fixture without logging secrets or personal content. Base64 is reversible encoding, not encryption, a signature, or proof of authorization; use TLS and the API's designated authentication mechanism. If a test uses sensitive data contrary to policy, stop and follow the data owner's incident procedure rather than assuming the encoding protected it. (Sources 1, 4)
THE HELPER CREW
Tools for the fiddly bits.
These are the currently published Nirmion tools matched to this guide. Open a tool page for its accepted inputs and limits.
RECEIPTS, PLEASE
Sources & review notes
Each source is linked to the steps it supports. Open it to check its scope and current guidance.
Source checked 2026-10-10