Java Escape Online — Escape Strings for Java

Escape \, ", \n, \t, and control characters for Java double-quoted string literals. Browser-only — paste raw text, copy a literal-safe string.

Raw Input

Java String Literal Output

What is Java String Escaping?

Java string escaping converts a raw string into a form valid as a Java double-quoted string literal — backslashes are doubled, double quotes prefixed with backslash, and control characters (\n, \r, \t, \b, \f) emitted as their two-character escape sequences. The result can be pasted between " marks in a .java file without breaking compilation.

Java has two literal forms: traditional double-quoted strings that interpret backslash sequences and text blocks (Java 15+, """...""") that preserve newlines literally. This tool produces traditional-string output and runs entirely in your browser. Useful for code-generation, embedding multi-line content as a single string constant, and escaping regex or SQL templates.

How to escape Java strings — 4 steps

Paste raw text. Drop your unescaped string into the Input panel — Windows paths, multi-line text, regex patterns all welcome.
Click Escape. Backslashes are doubled first, then quotes and control characters are emitted as backslash sequences.
Verify. Every \ shows as \\, every " as \", and every newline collapses to \n on a single line.
Paste into Java. Wrap the output in double quotes and drop into a String declaration, final constant, or test fixture.

Sample input and output

Raw input

SELECT * FROM users WHERE name = "Doe" AND id = 42
Path: C:\logs\app.log
	(indented row)

Java string literal

SELECT * FROM users WHERE name = \"Doe\" AND id = 42\nPath: C:\\logs\\app.log\n\t(indented row)

JLS Compatible

Uses the exact backslash sequences the Java Language Specification defines for double-quoted string literals — \\, \", \n, \r, \t, \b, \f.

Backslash-First

Doubles backslashes before any other replacement so subsequent passes do not re-encode the new backslashes — paths and regex come out right.

Browser-Only

No source code or string content leaves the browser. The transformation is pure JavaScript on your machine.

Common use cases

check_circleEmbedding Windows file paths in Java code as traditional string literals
check_circlePreparing regex patterns for Pattern.compile without verbose escaping
check_circleConverting JSON or YAML payloads into Java String constants for tests
check_circleEncoding multi-line SQL queries as single-line Java strings
check_circleStoring escaped XML or HTML templates as compile-time constants
check_circleGenerating string literals for code-generation libraries (JavaPoet, KotlinPoet)
check_circlePreparing fixtures for JUnit, TestNG, and Spring Boot test assertions
check_circleEmbedding API request/response samples in Spring controller tests

Java escape vs JSON escape vs JavaScript escape

All three produce backslash-escaped strings, but each has its own ruleset. Java supports the common control set plus octal escapes (\0–\377) but no \v. JSON per RFC 8259 supports a small set: \", \\, \/, \b, \f, \n, \r, \t, \u00xx — anything else is invalid. JavaScript adds \', \v, \xNN, \u{NNNNN}, and template-literal-specific escapes. Output from one parser is not always valid in another.

Need to reverse the operation?

Decode existing Java escape sequences back to plain text, or compare with JavaScript and .NET escape behaviour.

Java Unescape JavaScript Escape .NET Escape

Frequently Asked Questions

Does it use \u00xx for non-ASCII?

No — non-ASCII characters are passed through unchanged because Java source files are compiled with a configurable encoding (UTF-8 by default in modern toolchains) and accept literal Unicode in string literals. If your build pipeline forces ASCII-only source, you can replace each non-ASCII character with its \u00xx escape after the basic escape pass — but that requirement is rare on modern projects.

What about modified UTF-8?

Modified UTF-8 is the encoding the JVM uses internally for class-file constants — it differs from standard UTF-8 in how it encodes the null character and supplementary code points. It is purely an internal detail; it does not change how you write Java source. The escape transformation here produces a valid Java source-level string literal regardless of the modified-UTF-8 wire format used inside the class file.

Do I need to escape single quotes in Java strings?

No. Inside a double-quoted string, the single quote is just an ordinary character. You only need to escape it (\') inside char literals ('a', '\''). The tool follows that rule and leaves single quotes alone in string output.

How does this compare with text blocks (Java 15+)?

Java 15 introduced text blocks (triple-quoted, """...""") which preserve newlines and quotes literally with much less escaping. If your target is Java 15 or later, paste raw multi-line content into a text block and skip the escape pass entirely. This tool produces a single-line traditional string literal — useful for older code, code-generation, and cases where you cannot use text blocks.

Can I use it for Java .properties files?

Almost. .properties files share the backslash escapes but additionally require escaping leading whitespace, the equals sign in keys, and use \u00xx for any character outside ISO-8859-1. The basic escapes here are correct, but for full .properties output you would add those rules. Modern projects often switch to UTF-8 .properties (Java 9+) which avoids most of the extra encoding.

What about Kotlin and Scala?

Kotlin and Scala both follow Java's escape conventions for traditional double-quoted strings, so the output of this tool is also valid Kotlin and Scala. Each language adds its own raw or interpolated string variants (Kotlin's """, Scala's s"...") that change the rules; for those, escape requirements differ.

Why is the backslash escaped first?

Order matters. If quote escaping ran first, the resulting \" would itself contain a backslash that the next pass would re-escape into \\". Doubling backslashes first is the only way to guarantee no double-encoding occurs in any character.

Is the input sent to a server?

No. The escape transformation runs entirely in JavaScript inside your browser. Java source often contains SQL templates, secrets, or business-logic constants — none of it leaves the device. Verify in the browser DevTools Network tab.