PasteCleanly / Text tools

Encode and decode text

Convert UTF-8 text or a single URL component into the representation another tool expects.

Text and opened files stay in this tab. How privacy works

Worked example

Original
Café & tea ☕
URL component encoded
Caf%C3%A9%20%26%20tea%20%E2%98%95

How to use this tool

Pick the right representation

Use Base64 for standard text payloads and Base64URL when the destination expects the URL-safe alphabet. Decoding Base64 is not decryption. Anyone with the encoded value can decode it.

Encode one URL value at a time

If you are building a link, encode the query value, not the complete URL. In URL component mode a space becomes %20. Choose form value mode only when the recipient uses + for spaces. A literal plus is encoded as %2B.

Read decoding errors

Check the alphabet and direction if the input is rejected. This tool decodes UTF-8 text, not images or binary files. If the source text is already garbled, such as café, try Fix broken accents rather than re-encoding it.

Encode the right part of your text for the right destination

Choose a representation based on the receiving format

Start by finding out what the recipient expects. A field marked Base64 may expect standard Base64; a field specifically marked Base64URL may expect the URL-safe alphabet. These formats turn bytes into text characters. A URL component, on the other hand, is text escaped so that it can sit in a part of a link without being mistaken for punctuation that structures the link. A form value is another convention, with different handling for spaces. The right choice depends on the contract, not on which output looks shorter.

Base64 is useful when a text-based format needs to carry a sequence of bytes. This tool starts from text and uses UTF-8. It can also interpret encoded bytes as UTF-8 text in the other direction. Do not use it as a general file encoder for an image, a PDF or an archive. You may get Base64 that is syntactically valid but does not represent a text file this editor can display.

If someone sends you a strange-looking value, ask whether it came from a URL, a payload or a file before changing it. A value containing percent signs may need URL decoding, while a value ending in equals signs may contain Base64 padding. Those clues are not definitive. A literal sentence can contain a percent sign, and some Base64 variants omit padding. Work with the source instructions whenever possible.

Round-trip a short UTF-8 sample

Paste Café & tea into Original and select Base64 with the encode direction. Copy the result, switch to Decode and paste it back. You should get the same phrase, including the accented letter and the ampersand. A short ASCII-only sample such as Hello would not test the accent. This is why including a real character from the intended language makes a better check.

If the decoded result looks wrong, compare it against the original a character at a time. A decoded string can contain a nonbreaking space, a tab or an invisible separator that looks ordinary in a text box. Use the invisible character inspector when the words look correct but your target rejects an exact comparison. If the original text already contained corrupted characters, Base64 will simply preserve that corruption; it cannot infer what the author meant.

A round trip tells you that the same representation can return your input here. It does not tell you that the system receiving the encoded value expects the same alphabet, padding or character encoding. Test a second sample using the receiving system's own decoder. If it handles English words but fails on accented letters or emoji, compare how each side interprets the decoded bytes. Preserve the original text and the exact encoded sample for diagnosis.

Return to the encoder and try a round trip

Encode a query value, not the entire URL

Suppose the query parameter is named q and its value should be Café & tea + milk. Paste only the value into URL component mode. The space becomes %20, a literal ampersand becomes %26 and the plus becomes %2B. The escaped value can then follow the q= part of your URL. The ampersand within the value should not create another parameter, and the plus should not be silently interpreted as a space.

A complete URL already contains punctuation with structural meaning. The colon after https, the slashes before the host, the question mark before a query and the equals sign after a parameter name are not normally part of the value being escaped. Encoding all of them together changes how the link is read. If you are using a program that builds URLs from structured values, it may already encode the parameter for you. Give that program the original value unless its documentation explicitly asks for a pre-encoded component.

A path segment is not always the same thing as a query value. If you are creating a new readable path from a title, use the slug converter and choose a naming convention. A slug intentionally rewrites the wording; percent encoding preserves the original value in a different notation. The title and slug guide shows why keeping those two tasks separate avoids confusing links.

Understand how forms treat plus signs

When a destination uses form-style encoding, a space is represented by a plus sign. A literal plus still needs to be encoded as %2B. This matters for terms such as C++: if the two plus signs are left raw in a form value, a form decoder may read two spaces instead. Paste C++ basics and compare the results in URL component and form value modes. The plus signs that belong to the programming language are escaped in both, but the space between the two words is written differently.

On decoding, the distinction works the other way. Decoding a component normally leaves a raw plus as a plus. Decoding a form value interprets a raw plus as a space. If you know the value came from a form submission or a system that uses that convention, choose the corresponding mode. If the source is an individual URL component and the plus is meant to be literal, do not assume that all decoding should convert it to whitespace.

Also distinguish percent encoding from HTML entities. The sequence %26 describes an escaped ampersand in a URL value. The spelling & represents an ampersand in HTML. Use the HTML entity tool for an HTML reference. It is possible to have both contexts in one snippet, such as a URL in HTML source, but each layer has to be handled for its own destination.

Diagnose rejected input without guessing at its contents

Check the selected direction and mode first. A Base64 decoder can reject punctuation from a URL or a value using the wrong alphabet. URL decoding can reject an incomplete percent sequence, such as a percent sign followed by only one hex digit. If you copied a sample from documentation, remove only surrounding code fences or a label that is not part of the payload. Do not strip characters from the value merely to make an error disappear.

A valid Base64 string can describe bytes that are not valid UTF-8 text. The proper next step is to identify what produced those bytes. If they came from a binary file or a different character encoding, changing the displayed text is not a reliable fix. If the decoded text looks like café, the problem may have occurred before encoding. The broken accent tool can help inspect a possible UTF-8 decoding mistake, but a clean export is preferable when you can get one.

Double encoding is another common cause of surprising values. If an already escaped %20 becomes %2520, one decoding pass returns the characters %20, not a space. That may be intentional in nested representations, but verify which layer the receiving application expects. Keep the untouched value, work on a small sample and apply the matching decoding operation once before deciding whether a second layer is present.

Treat encoded text as readable data, not a secret

Base64 and percent encoding are reversible. A long string can look unreadable without providing any privacy or authentication. Do not use either format to hide a password, a private token or customer data. A receiving service, application log or copied message may still reveal the original value. The fact that conversion runs in the browser does not change what happens after you put the result into a link or share it elsewhere.

For a reproducible support example, replace sensitive values with invented text before encoding. Preserve the type of tricky character you need to test: a space, an ampersand, an accent or a literal plus. That lets another person diagnose the encoding behavior without seeing the real value. If an encoded payload belongs to a larger structured document, verify that the rest of the document still parses after you replace just the affected field. Use the JSON formatter for a syntax check when the container is JSON.

Before handing off the result, write down the chosen representation, direction and a short expected decoded value. Test the actual recipient's workflow once with a harmless sample. If it produces the original text and the surrounding URL or document remains valid, you have checked both the conversion and its context. This is more useful than assuming any value that looks encoded is ready to paste.