Goal
Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8.
Base64 Encode and Decode
Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8.
Key facts
- What it does
- Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8.
- Formula
Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed.- You enter
- Operation · Text or Base64 input
- Worked example
- Hello, world! encodes as SGVsbG8sIHdvcmxkIQ==.
A clearer path to an answer
From your question to a useful result
This page keeps the calculation transparent: define the goal, enter the matching values, inspect the method, and decide what the result means in your situation.
Inputs
Operation · Text or Base64 input
Method
Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed.
Next step
Calculate, review the assumptions below, then compare a related tool when the decision needs more context.
Base64 Encode and Decode
Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8.
Open the Base64 Encode and Decode pageMore technology tools
Download PDFDownload Word (.doc)
Result
Enter your values above and choose Calculate to see the result here.
Calculation map
Follow the path from input to answer
01
Inputs (2)
- Operation Ready
- Text or Base64 input Ready
02
Formula
Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed.
Bounded, transparent calculation
03
Result
- Calculate to preview the result.
Recent runs
Your recent runs stay in this browser session only.
Formula, assumptions, and example
Formula: Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed.
The implementation encodes Unicode as UTF-8 bytes and rejects invalid standard Base64 alphabets or padding during decoding.
- The text mode uses UTF-8.
- The standard RFC 4648 alphabet is used rather than the URL-safe variant.
Worked example: Hello, world! encodes as SGVsbG8sIHdvcmxkIQ==.
Displayed input contract
- Operation · 2 choices
- Text or Base64 input
The displayed limits are checked before the handler runs. Model-specific domain checks may also reject impossible or non-finite inputs.
Methodology: This calculator follows the WorldCalculate input, formula, precision, and boundary policy. Read the official methodology.
Calculator usage statistics
Usage of this calculator and related tools
This section counts anonymous successful Calculate submissions, not unique visitors. Counts and top tools appear only when trusted aggregate data is available; country analysis is shown only under the same condition and reporting threshold.
Total successful calculations
Top tools
Country analysis
Most-used tools
Where usage is reported
Answer-first guide
How to use the Base64 Encode and Decode for a real question
Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8. Start with one clearly defined goal, enter values in the units shown, and keep the result attached to the assumptions below.
What this answers
This tool is useful when your question includes base64, encode, decode. It returns the outputs declared in the calculator contract rather than a live quote, approval, diagnosis, or professional sign-off.
What you enter
Operation · Text or Base64 input. Keep the same time period, unit system, and currency wherever the form requires comparable values.
How to check it
Run the worked example first, compare its output with the page's example, then change one input at a time. This makes an unexpected result easier to trace to a unit, boundary, or assumption.
Three checks before you rely on the answer
- Match the question. Confirm that the result means the quantity you need, not a similar-sounding percentage, balance, rate, or estimate.
- Match the inputs. Use the requested units and period, and read each hint before replacing the example values with your own.
- Read the boundary. Review the assumptions and limits. The text mode uses UTF-8.
Need a wider view? Browse Technology Calculators or compare the related tools below. The WorldCalculate methodology explains how formulas, examples, limits, and revisions are reviewed.
How to use the Base64 Encode and Decode
- Enter Operation.
- Enter Text or Base64 input — Base64 is encoding, not encryption.
- Choose Calculate and read the result panel.
- Use Download PDF or Download Word to save a result sheet.
Formula
Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed.
The implementation encodes Unicode as UTF-8 bytes and rejects invalid standard Base64 alphabets or padding during decoding.
Worked example
Hello, world! encodes as SGVsbG8sIHdvcmxkIQ==.
Assumptions and limits
- The text mode uses UTF-8.
- The standard RFC 4648 alphabet is used rather than the URL-safe variant.
Context and background
The representations behind technical results
Computing tools distinguish number bases, decimal and binary storage, network prefixes, transfer units, and visual ratios before performing the arithmetic.
Technical systems use several measurement conventions because software, hardware, networks, and design each describe quantities differently. Explicit representation prevents a familiar abbreviation from hiding a different definition.
Research and review
How this guide was researched
Researched by Hassan ALRowaie, Founder and editorial researcher at WorldCalculate.
This guide follows the live calculator's declared inputs, formula, worked example, assumptions, validation boundaries, and source-backed methodology. The review date describes editorial review of the calculator explanation; it is not a promise that external facts or rates remain current.
Base64 is a reversible way to represent bytes with a small text alphabet. This calculator has two explicit modes: encode UTF-8 text into standard padded Base64, or decode standard padded Base64 back into UTF-8 text. It is useful when a byte sequence must travel through a text-only field, be inspected in a log, or be included in a format that expects ordinary characters. It does not hide meaning, establish identity, protect a secret, or replace encryption. The page uses the standard alphabet with uppercase letters, lowercase letters, digits, plus, slash, and equals padding. It does not accept the URL-safe alphabet as a substitute. The guide below follows the exact input contract, explains byte grouping and padding, works through text and Unicode examples, describes decoder validation, and marks the boundary between encoding and security.
What Base64 actually does
Base64 changes the representation of data without changing the underlying bytes. A text encoder first turns the entered string into UTF-8 bytes. The Base64 step then represents those bytes with printable characters chosen from a fixed alphabet. A decoder reverses that mapping and interprets the recovered bytes as UTF-8 text. If the bytes form valid UTF-8, the original visible text is recovered; if they do not, the decoder reports an error rather than inventing replacement characters.
The word encode can sound like a security operation, but it is not. Anyone who knows the format can decode a Base64 value, and the output often makes the transformation obvious. The purpose is compatibility and transport, not secrecy. A Base64 string can be longer than the original byte sequence because several bits of representation are spent on text characters and padding. That extra length is a normal consequence of the format, not evidence that the data has been strengthened.
This page keeps the operation small enough to audit by hand. It receives one operation choice and one text field, applies the selected transformation, and returns one text result. It does not parse a surrounding document, detect an embedded payload, fetch a key, inspect a file type, or decide whether a decoded message is trustworthy. Those decisions remain with the person or program that owns the data context.
- Encoding changes representation; it does not provide confidentiality.
- Decoding reverses standard Base64 only when the bytes are valid UTF-8 text.
- The calculator works with one input string at a time.
- Context, ownership, and interpretation are outside the arithmetic contract.
Choose the operation first
The Operation field offers Encode UTF-8 text and Decode Base64. Choose encode when the input is ordinary text that should become a Base64 representation. Choose decode when the input already consists of a standard Base64 string and the desired result is readable UTF-8 text. The same characters can be valid text in one mode and invalid Base64 in the other, so the operation choice is not a cosmetic label. It determines which validation and transformation path runs.
In encode mode, the input can contain spaces, punctuation, line breaks, accented letters, or other Unicode characters supported by the browser's UTF-8 text model. The encoder does not try to interpret the text as an existing Base64 value. If you type SGVsbG8sIHdvcmxkIQ== in encode mode, the page encodes those literal characters again instead of decoding them first. Avoid performing an unrequested second transformation.
In decode mode, the input must use the standard alphabet and its allowed padding pattern. The decoder trims outer whitespace before validation, but a string with an internal unexpected character, an incomplete group, or misplaced padding is rejected. After alphabet and padding checks, the recovered bytes are decoded as UTF-8. A value can therefore pass the Base64 shape check and still fail the text check if its bytes do not form valid UTF-8.
- Encode means text to UTF-8 bytes to Base64 characters.
- Decode means standard Base64 characters to bytes to UTF-8 text.
- The selected mode controls both validation and output labeling.
- Do not assume that a familiar-looking string is already in the required mode.
Text becomes UTF-8 bytes
Base64 itself operates on bytes, not on abstract letters. When this calculator encodes text, it uses UTF-8 to choose the bytes for that text. Basic Latin characters commonly occupy one byte, while many accented symbols, writing-system characters, and emoji occupy multiple bytes. The visible character count is therefore not always the byte count. That distinction matters because Base64 groups bytes, and the amount of padding depends on the byte count rather than on how many symbols a person sees.
For example, the word cafe can be represented with four ordinary ASCII bytes, while a spelling that uses an accented final character may require more than four UTF-8 bytes. Both are legitimate text inputs, but their encoded outputs need not have the same length. A decoded result is compared with the original at the text level only after the bytes have been converted back through UTF-8. Copying through a system that changes text normalization can also change the byte sequence even when the result looks similar.
The calculator does not offer a separate byte-array field or a character-set selector. Treat the input as Unicode text and let the stated UTF-8 contract do the conversion. If your real data is binary rather than text, a successful-looking text decode is not proof that the binary data has meaning as a sentence. The page is intentionally a text codec, not a general binary file inspector.
- Base64 groups bytes, not visual characters.
- UTF-8 may use several bytes for one visible symbol.
- Encoded length follows byte length and padding, not just character count.
- The page does not inspect arbitrary binary files as typed objects.
The 24-bit grouping idea
The standard Base64 algorithm takes up to three input bytes at a time. Three bytes contain 24 bits. Those bits are divided into four groups of six bits, and each six-bit value selects one character from the 64-character alphabet. This is why the output is built in groups of four characters. The operation does not compress the information; it repackages the bits so that each group can be written with a normal text character.
A six-bit value ranges from zero through 63. The first part of the alphabet assigns values to uppercase letters, then lowercase letters, then digits, followed by plus and slash. The exact order matters. A decoder must use the same table in reverse, which is why arbitrary substitutions or visually similar punctuation do not count as valid standard Base64. The mapping is mechanical, not language-dependent.
When the final input group has fewer than three bytes, the algorithm still emits a complete four-character group by using zero bits for the missing positions and marking the unused positions with equals signs. Those equals signs are padding indicators. They do not represent additional source data. Understanding the grouping makes it easier to see why output lengths appear in multiples of four and why an incomplete final group should not be silently guessed.
- Three bytes provide 24 bits.
- Four six-bit values select four Base64 characters.
- The standard alphabet has 64 data characters.
- Equals signs mark unused positions in the final group.
Read standard padded output
A standard encoded result is normally a sequence whose length is divisible by four. It may end with no padding, one equals sign, or two equals signs, depending on the number of source bytes in the final group. A result ending in two equals signs generally came from one remaining source byte, while one equals sign generally corresponds to two remaining source bytes. The padding pattern is a structural clue, not a secret marker and not a checksum.
The output alphabet is deliberately plain: uppercase A through Z, lowercase a through z, digits zero through nine, plus, and slash. Standard padded Base64 is different from a URL-safe variant that substitutes other characters and may omit padding. This page does not normalize one variant into the other. If another system specifies a different alphabet or an unpadded convention, that system's contract must be followed outside this calculator.
An empty encoded input produces an empty output because there are no bytes to represent. A short input can still create four output characters because the final group is padded to its complete display width. Do not judge correctness by output length alone. Compare the mode, alphabet, padding, and decoded text or bytes with the contract of the system that produced the value.
- Standard output length is a multiple of four.
- Zero, one, or two equals signs may appear at the end.
- Plus and slash belong to the standard alphabet used here.
- Length alone cannot prove that a value came from the expected source.
Worked encoding example
Use the example text Hello, world! in encode mode. The visible string is first represented as UTF-8 bytes. Because every symbol in this particular phrase belongs to the ordinary single-byte range, the byte sequence has one byte per visible character. The encoder groups those bytes into sets of three, maps each six-bit portion through the standard alphabet, and fills the last group with padding where needed.
The resulting text is SGVsbG8sIHdvcmxkIQ==. The two equals signs tell us that the final group did not contain three complete source bytes. They do not mean two extra characters were part of the original greeting. If the result is copied into decode mode without changing any characters, the recovered text is Hello, world!, which demonstrates the reversible representation step.
This example is useful as a small round-trip check because it exercises punctuation, a space, uppercase and lowercase letters, and standard padding. It is still only a codec example. The result should not be treated as a password, a credential wrapper, or an access token merely because it looks less readable than the original sentence.
- Input text: Hello, world!.
- Mode: Encode UTF-8 text.
- Output: SGVsbG8sIHdvcmxkIQ==.
- Decoding that output returns the original text.
Decode validation happens in stages
The decoder does not immediately treat every character as data. It first trims whitespace at the outside of the input and checks the complete string against the standard alphabet and padding structure. Data characters must appear in groups of four, and padding may occur only in the permitted final positions. A stray punctuation mark, an invalid group length, or an equals sign in the middle causes the input to be rejected as invalid alphabet or padding.
After the shape check, the browser converts the Base64 characters into bytes. The last stage asks whether those bytes form valid UTF-8. This distinction is valuable because Base64 is capable of representing arbitrary byte values, while this page promises a text result. The decoder therefore refuses malformed UTF-8 rather than silently replacing damaged bytes and presenting a different message as though it were original.
A failed decode is information about the input contract, not evidence that the page is missing a hidden conversion step. Check whether the value was copied with punctuation, whether a line was truncated, whether padding was removed, and whether the producing system used a URL-safe alphabet. Also check whether the original data was binary. Repeatedly changing characters until an output appears would destroy the audit trail.
- Outer whitespace is trimmed before standard validation.
- Alphabet and padding are checked before byte decoding.
- The recovered bytes must be valid UTF-8 text.
- Malformed input is rejected rather than repaired silently.
Padding and incomplete groups
Padding answers a simple question: how many source bytes were present in the last three-byte group? A source length divisible by three needs no padding. A remainder of two bytes produces one padding character, and a remainder of one byte produces two. The decoder uses that information to know which output bits are meaningful. Removing padding can be acceptable in a different protocol, but it is not the standard padded input contract used by this page.
Consider a one-character ASCII input such as A. It has one byte. The encoder still emits four display characters, with two equals signs marking the two unavailable byte positions in the final group. A two-character input has two bytes and usually ends with one equals sign. A three-character input fills one complete group and needs no equals sign. These examples show why short strings can expand sharply in their displayed form.
Padding is not an optional decoration when a consumer expects canonical standard output. A decoder may be able to infer missing bits in some environments, but accepting a relaxed form can hide a mismatch between producer and consumer. This calculator chooses the stricter stated form so that a value can be checked against a predictable alphabet, group size, and final marker.
- No remainder means no equals padding.
- One leftover byte normally produces two equals signs.
- Two leftover bytes normally produce one equals sign.
- Unpadded variants are outside this standard padded contract.
Unicode and multi-byte text
Unicode makes the byte boundary especially important. A visible symbol can occupy more than one UTF-8 byte, so a sentence containing non-ASCII characters can produce a longer Base64 result than a sentence with the same number of visible characters made only from basic Latin symbols. The encoder handles this through the browser's TextEncoder behavior rather than by assigning one arbitrary byte to each displayed symbol.
The reverse path uses a fatal UTF-8 decoder. When the encoded bytes form a valid sequence, the original Unicode text is reconstructed. A malformed sequence is not a near miss that should be corrected by guessing. Rejecting it protects the meaning of the text contract: the output must be a valid UTF-8 string, not an arbitrary collection of replacement glyphs that may conceal data loss.
Copy and paste can still affect what is being tested. A smart punctuation substitution, a changed normalization form, or a line-break conversion can produce different bytes while appearing visually close. When an exact round trip matters, preserve the original string and compare the decoded result to that original at the application level. The calculator can verify the codec transformation, but it cannot know which Unicode normalization policy another system intended.
- Visible character count and UTF-8 byte count can differ.
- Multi-byte symbols change grouping and output length.
- Invalid UTF-8 is rejected after Base64 syntax passes.
- Visual similarity is not proof of byte-for-byte equality.
Base64 is not encryption
Encoding and encryption solve different problems. Base64 uses a public, fixed mapping, so a reader does not need a key to reverse it. It does not create confidentiality, prevent copying, prove who produced the value, or make a weak secret stronger. A string of random-looking Base64 characters may contain a secret, but the representation itself does not protect that secret from someone who can read the string.
Do not place passwords, private keys, recovery codes, or other sensitive material into Base64 with the expectation that the result is safe to share. If an application needs confidentiality, it must use an appropriate encryption design with key management, authenticated integrity protection, and an operating context that understands the threat. Those requirements cannot be supplied by this two-field text converter.
The security boundary also applies to decoded output. A successful decode does not make the resulting text trustworthy. Treat decoded content as untrusted input when it will be displayed, parsed, executed, or passed to another system. Validate it according to that system's own rules and escape it for its destination. This page reports text; it does not approve an action based on that text.
- Base64 has no secret key.
- It does not provide confidentiality, authentication, or integrity.
- Sensitive values need a real security design, not a representation change.
- Decoded text remains data that must be handled according to its destination.
Standard alphabet versus URL-safe forms
The standard alphabet used here includes plus and slash. Some other protocols choose a URL-safe alphabet that substitutes hyphen and underscore so the encoded value is less likely to be interpreted as punctuation in a path or query component. Some also remove equals padding. Those are related formats, but they are not interchangeable character for character. A producer and consumer must agree on the variant before a value is copied between systems.
If an input contains hyphen or underscore where standard Base64 expects plus or slash, this decoder rejects it. That result is deliberate rather than an inability to recognize an obvious family resemblance. Quietly translating variants could make it harder to detect that a producer used a different contract. If you know the source is URL-safe, convert it under that source's documented rules before using a standard padded decoder.
The same caution applies to line wrapping and transport escaping. A system might insert line breaks, percent-escape punctuation, or surround the value with delimiters. The calculator accepts one standard Base64 string after outer whitespace trimming; it does not remove arbitrary wrappers or decode an outer transport layer. Keep each transformation separate so a later reader can tell which step produced which text.
- This page uses plus and slash for the final two alphabet positions.
- Hyphen and underscore indicate a different common variant.
- Missing padding may also indicate a different protocol contract.
- Outer transport escaping must be handled separately.
Input size and browser behavior
The input field is text with a maximum of 100,000 characters in the handler. That bound keeps a single browser calculation finite and prevents an unexpectedly large paste from turning a simple page into an uncontrolled memory task. It is a calculator input limit, not a universal Base64 limit. Other programs may choose smaller or larger limits based on their message format, memory budget, request size, and processing policy.
Encoding can expand the displayed string because every group of up to three bytes becomes four characters. A long Unicode input can expand according to its UTF-8 byte count rather than its visible character count. Decoding can also produce a result whose byte length is different from the number of Base64 characters. Plan storage and transport using the actual byte and text contracts of the surrounding system rather than relying on a visual estimate.
The page performs the operation locally in the browser and returns a text result. That does not make every surrounding workflow safe automatically. A browser history, clipboard, screenshot, log, or copied page content may retain a value. Avoid pasting sensitive material into a public or shared environment, and remember that the codec itself does not sanitize or classify the data.
- The handler accepts text up to 100,000 characters.
- Encoded length depends on UTF-8 byte length.
- The bound is a page contract, not a format-wide limit.
- Local browser processing does not remove clipboard or display risks.
A disciplined round-trip check
A round-trip test uses a known text input, encodes it, then decodes the exact returned string. The decoded result should match the original text under the same UTF-8 interpretation. This is a useful check for basic transformations, copied examples, and a new integration. It does not prove that a separate system will accept the value, because that system may require a different alphabet, padding policy, field wrapper, or character normalization rule.
Keep the intermediate value unchanged while testing. Do not insert spaces for readability, remove trailing equals signs, replace punctuation, or pass the result through a form encoder unless that additional step is part of the intended protocol. If a round trip fails, record the original input, selected mode, exact encoded text, and the point at which a character changed. A reproducible comparison is more useful than a series of manual guesses.
For an independent hand check, count the input bytes, group them in threes, and inspect the final padding. Then compare the four-character output groups with the calculator. For Unicode, inspect bytes rather than assuming one byte per symbol. The page is particularly good for verifying a small known sample; a larger integration should also test the actual receiving and producing components.
- Start with a known text sample.
- Encode the sample and decode the exact result without edits.
- Compare text after both steps use the same UTF-8 contract.
- Test the real neighboring system separately when variants are involved.
Common decode failures
An invalid alphabet error usually means that at least one character is outside the standard set, or that punctuation from another encoding layer was copied into the field. Check for hyphen, underscore, percent signs, quotes, commas, or a label that was included with the value. A length error often indicates that the text was truncated or that unpadded data was supplied to a standard padded decoder. The visible message points toward the shape of the problem, not toward the original content.
A value can also have a valid alphabet and padding arrangement but fail during UTF-8 decoding. That happens when the bytes are arbitrary binary data, damaged in transit, or produced under a different text encoding. Do not fix this by deleting bytes until the decoder accepts them. First identify whether the source promised text, then use a binary-aware tool or the source's declared character encoding if the data is not UTF-8.
Successful output can still be wrong if the wrong substring was copied. A wrapper may contain a prefix, suffix, version marker, or multiple fields. The calculator treats the complete input as one Base64 value. Separate the field according to the owning format before decoding, and preserve the original wrapper in your notes so the transformation can be repeated.
- Check for nonstandard punctuation and copied labels.
- Check whether padding or characters were lost during copying.
- Distinguish invalid UTF-8 text from arbitrary binary bytes.
- Decode the intended field, not an entire surrounding record.
When this calculator is a good fit
This page is a good fit for learning the standard mapping, checking a short text sample, verifying padding, and confirming that a known value makes a clean encode-decode round trip. It can help explain why a text-only field contains letters, digits, plus, slash, and equals signs instead of the original punctuation. It is also useful when documenting a simple data handoff whose contract explicitly names standard padded Base64 and UTF-8.
It is not a replacement for a file parser, protocol implementation, encryption library, data-loss recovery process, or binary hex viewer. It does not know whether an encoded string represents an image, a document, a token, or ordinary prose. Those interpretations require metadata and a trusted application contract. The calculator should answer the representation question only: what standard padded Base64 corresponds to this text, or what UTF-8 text corresponds to this valid Base64 input?
Keep that narrow question visible when you copy the result into another workflow. Record the selected direction, the text encoding, the Base64 variant, whether padding is required, and any outer transport transformation. Clear explanations prevent a harmless representation tool from being mistaken for a security control or a universal decoder.
- Use it for standard padded Base64 and UTF-8 text checks.
- Use a separate binary-aware tool for non-text bytes.
- Use a separate security design for confidential data.
- Document the variant and outer transport rules around the result.
A precise final checklist
Before encoding, confirm that the input is the exact text you intend to represent and that UTF-8 is the expected character encoding. Select Encode UTF-8 text, calculate, and inspect the standard alphabet and final padding. Before decoding, confirm that the copied value is standard padded Base64 rather than a URL-safe or unpadded variant. Select Decode Base64 and expect both a valid Base64 structure and valid UTF-8 bytes.
After the result appears, compare it with the owning system's contract. A correct Base64 result can still be rejected by a consumer that expects a different variant, a line-wrapped value, a transport-escaped value, or a field wrapper. Conversely, a consumer that accepts relaxed syntax may be hiding a mismatch that this page intentionally exposes. Exact format agreement is part of correctness.
Finally, keep the security boundary in the record. Base64 is reversible encoding, not encryption. It does not make secrets safe, authorize a request, validate decoded instructions, or prove data integrity. With those limits stated plainly, the calculator remains useful: it gives a transparent text transformation, rejects malformed standard input, and makes the byte and padding rules easier to reason about.
- Confirm UTF-8 text before encoding.
- Confirm standard alphabet and padding before decoding.
- Check the surrounding system's variant and wrapper rules.
- Never treat Base64 as a security boundary.
Frequently asked questions
What is the Base64 Encode and Decode?
Encode UTF-8 text to standard padded Base64 or decode valid Base64 back to UTF-8.
What is the formula for the Base64 Encode and Decode?
Base64 maps 24-bit byte groups to four 6-bit characters and uses = padding when needed. The implementation encodes Unicode as UTF-8 bytes and rejects invalid standard Base64 alphabets or padding during decoding.
What do I need to use this calculator?
Enter Operation, Text or Base64 input, then choose Calculate.
What are the limits of this calculator?
The text mode uses UTF-8. The standard RFC 4648 alphabet is used rather than the URL-safe variant.
Methodology
This calculator is part of the WorldCalculate library. Its formula, example, assumptions, input bounds, and output formatting follow the official methodology.
Use this calculator as part of a bigger plan
These WorldCalculate collections connect this tool with related questions while keeping each calculation separate and transparent.