Java Escape
Paste text and get a ready-to-paste Java string literal body with all special characters escaped.
Example
Input:
Say "hi"
Path: C:\temp café
Output (paste between double quotes):
Say \"hi\"\nPath: C:\\temp\tcafé
How it works
Type or paste text in the input and the escaped Java string body appears instantly. Wrap the output in double quotes to use it as a Java string literal.
Good to know
Java Escape turns any raw text into the inside of a Java string literal, escaping every character that would otherwise break your source code. Paste a Windows file path, a regex, a snippet of JSON, or a multi-line message, and it returns a single line with backslashes doubled, double quotes prefixed with a backslash, and control characters such as newline, carriage return, tab, backspace and form feed rewritten as \n, \r, \t, \b and \f. Anything outside the printable ASCII range (below 0x20 or above 0x7E) is converted to a \uXXXX escape so the result stays pure ASCII and survives any file encoding.
It is aimed at Java and JVM developers (Kotlin, Scala and Groovy share the same escape rules for double-quoted strings) who need to hard-code a value without hand-counting backslashes. Reach for it when you are pasting a file path like C:\Users\me into code, embedding a regular expression, inlining a small block of formatted text, or building a test fixture where a string with quotes and tabs must round-trip exactly.
To read the result: the output is only the body of the literal, not the wrapping quotes. Drop it between two double quotes yourself, for example String s = "...";. The status line reports how many input characters became how many output characters, which is a quick sanity check that escaping expanded the text as expected. A surrogate pair such as an emoji counts as two UTF-16 code units and therefore produces two consecutive \u escapes.
One practical caveat: because non-BMP characters are emitted as surrogate-pair escapes rather than a single code point, the escaped form is verbose but always valid in older toolchains and any source encoding. If you would rather keep readable accented letters or emoji literally in a UTF-8 source file, you only strictly need to escape backslashes, double quotes and control characters; this tool deliberately escapes all non-ASCII for maximum portability. To reverse the process, use the companion Java Unescape tool.
Frequently asked questions
Does the output include the surrounding double quotes?
No. It produces only the literal body. Wrap it yourself, e.g. String s = "
How are non-ASCII characters like accents or emoji handled?
Any character below 0x20 or above 0x7E is emitted as a \uXXXX escape based on its UTF-16 code unit, so the result is pure ASCII and safe in any source encoding. Characters outside the BMP become two \u surrogate escapes.
Is my data uploaded anywhere?
No — this tool runs entirely in your browser. Your input never leaves your device and it works offline once loaded.
Is it free?
Yes, completely free with no sign-up and no limits.
People also ask
How do you escape a backslash in a Java string?
A literal backslash is written as two backslashes (\\) inside a Java string. So a Windows path like C:\temp becomes C:\\temp in the source code.
What is the difference between escaping and unescaping a Java string?
Escaping converts raw text into a safe string-literal body by adding backslash sequences, while unescaping does the reverse, turning a literal like \n or é back into the actual newline or character it represents.
Do you need to escape single quotes in a Java string?
No. Single quotes (') do not need escaping inside a double-quoted Java string; only the double quote (") must be escaped as \". Single quotes only require escaping inside char literals.
How are emoji and characters outside the BMP escaped in Java?
Characters above U+FFFF are stored as a UTF-16 surrogate pair, so they are written as two consecutive \uXXXX escapes, one for the high surrogate and one for the low surrogate.
Does Java have raw or multi-line string literals that avoid escaping?
Java text blocks, introduced in Java 15 and delimited by triple double quotes, let you write multi-line text with fewer escapes, but backslashes and embedded triple quotes still follow escaping rules. There is no fully raw, no-escape string literal in Java.
Can the same escaped output be used in Kotlin or Scala?
Largely yes, because Kotlin and Scala double-quoted strings use the same core backslash and \uXXXX escapes as Java. Kotlin also has its own raw string syntax with triple quotes that does not interpret these escapes.
Why is a newline shown as \n instead of an actual line break?
A real line break inside a Java string literal is a syntax error, so the newline character is represented by the two-character sequence \n, which the compiler converts back to a line feed at runtime.
Related tools