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.