complete.tools

String Obfuscator

Turn text into Base64, URL-encoded, ROT13 and hexadecimal forms for light obfuscation or data transport. These are encodings, not encryption.

What this tool does

Turn text into Base64, URL-encoded, ROT13 and hexadecimal forms for light obfuscation or data transport. These are encodings, not encryption. You fill in these fields: Input text. It shows base64, URL encoded, ROT13, hex (UTF-8 bytes), and UTF-8 bytes.

Inputs

  • Input text: Longer text, up to 5000 characters.

How to use

  1. Type the input text.
  2. Read the result: base64, URL encoded, ROT13, hex (UTF-8 bytes), and UTF-8 bytes. It appears once every required field has a valid value.
  3. Use the copy button to copy the text.

Worked examples

Example 1. Inputs:

  • Input text: "Hello World"

Results:

  • UTF-8 bytes: 11
  • Note: These forms hide nothing from anyone who knows how to read them. Do not use them to protect passwords or private data.

How this is worked out: ASCII bytes of "Hello World" are 48 65 6c 6c 6f 20 57 6f 72 6c 64 (11 bytes). Base64 of that is the well-known SGVsbG8gV29ybGQ=. Space is %20. ROT13 moves each letter 13 places (H to U, e to r, l to y, o to b, W to J, r to e, d to q).

Example 2. Inputs:

  • Input text: "café!"

Results:

  • UTF-8 bytes: 6
  • Note: These forms hide nothing from anyone who knows how to read them. Do not use them to protect passwords or private data.

How this is worked out: UTF-8 bytes: c 63, a 61, f 66, e-acute C3 A9, ! 21 (6 bytes). Base64 groups 636166 -> 011000 110110 000101 100110 -> Y 2 F m, and C3A921 -> 110000 111010 100100 100001 -> w 6 k h. RFC 3986 percent-encodes the two bytes of e-acute and also "!". ROT13: c to p, a to n, f to s; e-acute and ! are not A to Z so stay.

Example 3. Inputs:

  • Input text: "a+b=c/d e"

Results:

  • UTF-8 bytes: 9
  • Note: These forms hide nothing from anyone who knows how to read them. Do not use them to protect passwords or private data.

How this is worked out: Bytes 61 2b 62 3d 63 2f 64 20 65 (9 bytes). Base64: 612b62 -> 011000 010010 101101 100010 -> Y S t i; 3d632f -> 001111 010110 001100 101111 -> P W M v; 642065 -> 011001 000010 000001 100101 -> Z C B l. + = / and space are percent-encoded as %2B %3D %2F %20. ROT13: a to n, b to o, c to p, d to q, e to r.

Example 4. Inputs:

  • Input text: "N-z_~.*"

Results:

  • UTF-8 bytes: 7
  • Note: These forms hide nothing from anyone who knows how to read them. Do not use them to protect passwords or private data.

How this is worked out: Reviewer vector. Bytes 4e 2d 7a 5f 7e 2e 2a (7 bytes). Base64: 4e2d7a -> 010011 100010 110101 111010 -> T i 1 6; 5f7e2e -> 010111 110111 111000 101110 -> X 3 4 u; the last byte 2a -> 001010 100000 -> K g, then == to pad a 1-byte group (RFC 4648 section 4). RFC 3986 section 2.3 leaves - . _ ~ as they are and encodes * as %2A. ROT13 wraps past Z: N (14th letter) to A, z (26th) to m (13th).

Limitations

  • Encodes only; to decode, use a decoder for the format.
  • Not secure: never use it to protect secrets.
  • ROT13 changes only the letters A to Z and a to z.
  • Base64 uses the standard alphabet with + and / and = padding, not the URL-safe one.
  • The byte count is UTF-8 bytes, not characters: an accented letter is usually 2 bytes and an emoji 4 or more.

FAQs

Q: Is this encryption?
A: No. Base64, URL encoding, ROT13 and hex are public formats that anyone can reverse in seconds. They only change how text looks.
Q: Does it work with accents, emoji and other languages?
A: Yes. Base64, URL and hex forms are built from the UTF-8 bytes of the text. ROT13 only changes the letters A to Z, so other characters stay as typed.
Q: Why is the hex longer than my text?
A: Each byte becomes two hex digits, and letters outside basic English take two to four bytes each.
Q: Does the URL form match encodeURIComponent?
A: Nearly. It follows RFC 3986, so it also encodes ! * ' ( ). A space is written as %20, never as a plus sign.

Explore Similar Tools

Explore more tools like this one: