Java With Us

Java Beautifier & Code Formatter

Paste minified or messy Java code and get it back properly indented. Runs entirely in your browser.

What the beautifier does (and doesn't)

This in-browser Java formatter applies the rules most developers intuitively expect:

  • One statement per line (splits after ;).
  • Consistent indent — 2, 4, or 8 spaces.
  • Egyptian braces: opening { at the end of the line, closing } on its own line.
  • Normalized commas (always a single space after).
  • Preserves string literals, "" text blocks, and ////* */ comments verbatim.
  • Collapses runs of blank lines to a single one.

What it does not do: enforce a line-length limit, wrap long method calls on a chain of fluent calls, align annotations to parameters, or apply a specific style guide to the letter. For those, reach for google-java-format, Spotless, or your IDE's built-in formatter (IntelliJ: Ctrl+Alt+L, Eclipse: Ctrl+Shift+F).

When is this tool useful?

  • You pasted code from a StackOverflow answer that lost its indentation.
  • You copied code from a one-liner jar / obfuscated source and need to read it.
  • You're reviewing a pull-request in a browser and want a cleaner view.
  • You want to quickly tidy a gist before sharing.
  • You need a quick paste-format-copy workflow without opening an IDE.

Style rules at a glance

SituationFormatter behavior
After {Newline, indent + 1
Before }Newline, indent − 1
After ;Newline at same indent
After ,Single space
Blank linesCollapsed to at most one
Strings / text blocksUntouched
CommentsUntouched

Before and after

Before — minified

package com.example;public class Greeting{private final String name;public Greeting(String n){this.name=n;}public String say(){return"Hello, "+name;}}

After — beautified

package com.example;

public class Greeting {
    private final String name;

    public Greeting(String n) {
        this.name = n;
    }

    public String say() {
        return "Hello, " + name;
    }
}

The Java style guides in 60 seconds

Four widely used Java code-style guides exist. This tool roughly follows their common ground:

  • Oracle Code Conventions (1999) — 4 spaces, Egyptian braces, historic default.
  • Google Java Style — 2 spaces, 100-column line limit, consistent method-chain wrapping. Widely adopted in open-source.
  • Android Open Source Project — 4 spaces, AOSP-specific conventions like mFieldName prefix (no longer recommended).
  • IntelliJ default — 4 spaces, some cosmetic differences from Oracle (alignment of continuation lines).

Formatting Java programmatically

For real projects, automate formatting in your build:

google-java-format — one-shot

java -jar google-java-format-1.22.0-all-deps.jar --replace src/**/*.java

Spotless with Maven

<plugin>
  <groupId>com.diffplug.spotless</groupId>
  <artifactId>spotless-maven-plugin</artifactId>
  <version>2.46.1</version>
  <configuration>
    <java>
      <googleJavaFormat/>
      <removeUnusedImports/>
    </java>
  </configuration>
  <executions>
    <execution><goals><goal>apply</goal></goals></execution>
  </executions>
</plugin>

Spotless with Gradle

plugins { id 'com.diffplug.spotless' version '6.25.0' }
spotless {
    java {
        googleJavaFormat('1.22.0')
        removeUnusedImports()
    }
}

Pre-commit hook

Add a Git hook that runs google-java-format --replace on staged .java files to prevent unformatted commits altogether.

Common formatting issues the tool handles

Minified code

Code without whitespace or line breaks (common after build-time minification or paste from a one-liner). The tool re-splits statements and indents properly.

Mixed tab / space indentation

Input with tabs and spaces mixed is normalized to pure spaces at the chosen size. Tabs inside string literals stay as tabs.

Tightly packed curly braces

Code like if(x){a();b();}else{c();} is expanded into a multi-line block with proper indentation.

Comments — preserved

Both // line and /* block */ comments are kept verbatim. The tool never rewrites text inside a comment.

Limitations of a regex-based formatter

A browser-side formatter can't understand Java syntax as deeply as a real parser. Cases where this tool falls short:

  • Generic brackets — Map<K, V>: the tool treats < and > as regular characters. Safe but won't align or wrap them.
  • Lambda bodies — multi-statement lambdas in arrays are formatted line-by-line; some projects prefer one-liners.
  • Annotations — placed on the same line as the element they decorate, not broken onto separate lines automatically.
  • Line-length limit — no automatic wrapping. Long lines stay long.

For strict style enforcement, run google-java-format on the result. That tool uses Eclipse's real parser and applies an opinionated style.

A brief history of Java code style

Java inherited its "Egyptian brace" style from C. Oracle published Code Conventions for the Java Programming Language in 1997 (revised 1999) — it remained the reference for almost two decades. Google released its internal style guide publicly around 2014; by 2020 it had become the most commonly adopted style in open source, thanks partly to the availability of google-java-format as a drop-in CLI.

The modern consensus: let an automated formatter own the decision. Teams argue less about spaces when a machine makes the call.