Java Unescape Online — Decode Java Escape Sequences

Decode Java string-literal escape sequences (\n, \t, \", \\) back to plain text. Browser-only — paste an escaped literal, copy the original characters.

What is Java String Unescaping?

Java string unescaping reverses the backslash-escape transformation a Java string literal applies — turning \n back into a newline, \t into a tab, \" into a literal double quote, and \\ into a single backslash. The result is the actual character data the literal represents at runtime.

Engineers commonly need this when copying a string constant out of a .java file for debugging, when comparing two strings that differ only in escape representation, or when extracting embedded SQL/JSON/regex from source code. The OpenFormatter Java unescape tool runs in your browser — paste the escaped body, click Unescape, copy the decoded result.

How to unescape Java strings — 4 steps

  1. Paste the literal body. Drop the contents of a Java string (without the surrounding quotes) into the Input panel.
  2. Click Unescape. Each escape sequence is replaced with the character it represents in reverse order so doubled backslashes survive correctly.
  3. Verify line breaks. Multi-line content now displays across multiple physical lines; tabs and quotes appear as themselves.
  4. Copy plain text. The decoded output matches what a running JVM would see in memory for that string constant.

Sample input and output

Escaped input

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

Decoded output

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

JLS Compatible

Decodes the standard Java string-literal escape set: \n, \r, \t, \b, \f, \", \\. The exact inverse of the Java escape tool.

Order-Aware

Backslash collapse runs last so doubled backslashes from the encoder survive every other replacement — paths and regex round-trip correctly.

Browser-Only

Decoding runs in JavaScript on your machine. Strings extracted from production .java files never leave the browser.

Common use cases

  • check_circleReading actual content of an escaped Java string constant
  • check_circleDebugging multi-line SQL stored as a single-line Java String
  • check_circleRecovering a Windows path from a Java traditional string literal
  • check_circleComparing two Java strings that differ only in escape representation
  • check_circleExtracting embedded JSON or XML out of a Java string fixture
  • check_circleInspecting log output that shows escape sequences instead of newlines
  • check_circlePulling the actual regex pattern out of a Pattern.compile call site
  • check_circleVerifying round-trip behaviour between encoder and decoder pairs

Java unescape vs JSON parse vs JavaScript unescape

All three reverse a backslash-escape transformation. Java unescape handles the JLS string set plus octal escapes (\0–\377). JSON parse per RFC 8259 supports only the strict set: \", \\, \/, \b, \f, \n, \r, \t, \u00xx — anything else is a syntax error. JavaScript unescape additionally decodes \', \v, \xNN, \u{NNNNN}. Picking the wrong unescape can either fail loudly or silently produce wrong output.

Need to escape, or compare with other languages?

Re-encode plain text as a Java string with the Java escape tool, or compare with JavaScript and .NET unescape behaviour.

Frequently Asked Questions

Which escape sequences are decoded?

The unescape pass handles the common Java string-literal set: \n (LF), \r (CR), \t (tab), \b (backspace), \f (form feed), \" (double quote), and \\ (backslash). It is the inverse of the OpenFormatter Java escape tool — round-trip-safe for the standard set.

How are \uXXXX Unicode escapes handled?

\uXXXX is processed by the Java compiler in a separate pre-tokenization pass — by the time strings reach normal parsing, those escapes are already characters. The current tool focuses on the source-level control set; for \uXXXX decoding paste the four-hex sequence into a JavaScript unescape tool which has explicit \uXXXX support.

What about octal escapes like \0 or \377?

Java permits octal escapes \0 through \377 inside string literals — a legacy feature inherited from C. They are uncommon in modern code, where \u00xx Unicode escapes or literal characters are preferred. This unescape tool does not currently expand octal sequences; if you encounter them, replace each by hand or run a Java compiler pass.

Why is \\ collapsed last?

The decode order is the reverse of the encode order. If \\ were collapsed first, the resulting single backslash could be misinterpreted by the next pass as the start of another escape (\n, \t). Doing it last guarantees the doubled-backslash from the encoder safely survives every other replacement.

Does it handle text-block content (Java 15+)?

Text blocks ("""...""") use the same escape sequences as traditional strings, but typically you do not need most of them — newlines and quotes are literal inside a text block. The few escapes that still apply (\\, \", \n) are handled correctly by this tool. For text-block content, paste the body and decode normally.

How is this different from the .NET unescape tool?

The common escape sequences (\n, \t, \r, \b, \f, \", \\) are identical between Java and C#. Differences appear in the rare extras — Java has octal escapes; C# adds \a (bell) and \v (vertical tab). For everyday strings the two unescape tools produce the same result.

Can I use it for Kotlin or Scala strings?

Yes for traditional double-quoted Kotlin and Scala strings — they share Java's escape syntax. Kotlin's raw triple-quoted strings ("""...""") and Scala's s-interpolation (s"$x") have their own rules and do not need traditional unescape passes.

Is the input sent to a server?

No. The decode runs in JavaScript inside your browser. Strings copied from .java source files — including SQL templates, secrets, and proprietary algorithms — never leave your machine. Verify in DevTools Network tab.

Java Unescape Online — Decode Java Escape Sequences