Go Formatter

What this tool does

The Go formatter rewrites Go source code into the one canonical style that the whole Go community uses. Paste a file or a snippet and it comes back with gofmt’s indentation, spacing, import grouping and aligned struct fields and comments.

It runs the real gofmt from the Go toolchain, compiled to WebAssembly. Nothing is approximated: what you see here is exactly what go fmt would write, so formatted code can be committed without causing a diff in CI.

How to use it

1. Paste Go code, or open a .go file.
2. The formatted code appears on the right as you type.
3. Keep Tab indentation for code you will commit. Pick 2 spaces or 4 spaces when the code is going into a document, a slide or a site that renders tabs too wide.
4. Copy or download the result.

If the code does not parse, the tool shows the first error with its line and column, for example expected ')', found '{', and you can jump straight to that line.

Example

The sample is a short program squeezed onto as few lines as possible: imports separated by semicolons, a struct on two lines, and functions with no spaces around operators. After formatting:

• the imports become a parenthesised block with one package per line;
• struct fields are put on their own lines and their types aligned in a column;
• if u.Age<18{ becomes if u.Age < 18 { with the body on its own line;
• composite literals get spaces after commas and colons.

What gofmt does and does not change

gofmt only changes layout. It never renames identifiers, reorders declarations or removes unused imports; those jobs belong to tools such as goimports and go vet. It also keeps your line breaks where they are meaningful, so a long argument list you split over several lines stays split.

Comments are kept and re-indented with the code around them. Trailing comments on consecutive lines are aligned into a column, just like struct fields.

Tips

• Formatting is a quick way to find a missing brace: the error position usually points at the first line after the mistake.
• Run the formatter before sharing code in an issue or a review. Reviewers can then focus on what the code does instead of how it looks.
• In your editor, enable “format on save” with gopls so your files always match this output.