b2KIT

Swift Formatter

Format Swift code following Apple style conventions with configurable indentation and line wrapping.

Tested tool guide Tested browser tools Checked August 16, 2026

What Swift Formatter does, with a checked example

Swift code arrives with tabs, spaces, and judgment calls mixed in, but Apple's whitespace conventions are mostly fixed rules: a space after the colon in `let x: Int`, spaces around operators, nothing inside the angle brackets of `Array<Int>`. This tool re-emits whatever you paste with those rules applied, plus configurable indentation and line wrapping, entirely in the browser, so the code never leaves the page. The surprise is what it will not do: it touches only whitespace and line breaks. Badly named variables, force unwraps, and other style sins pass through untouched.

Worked example

A concrete input and expected output from the current implementation.

Input

func add(a:Int,b:Int)->Int{
let sum=a+b
return sum
}

Expected output

func add(a: Int, b: Int) -> Int {
  let sum = a + b
  return sum
}

The colon, comma, arrow, and operator spacing all follow Apple's conventions, and the body is indented two spaces per the selected setting. No wrapping occurs because every line fits within the configured width. Reformatting the output returns identical text.

How the result is produced

1

Parse first, format second

The pasted text is parsed into a Swift syntax tree before any rewrite happens, and the rules operate on that tree. That is how the formatter tells a colon in `let x: Int` from a colon in `[String: Int]` or a ternary `a ? b : c`. Because parsing comes first, a snippet with a syntax error anywhere is rejected whole: you get an error, never a half-formatted result.

2

Deterministic rule set with two dials

Formatting is deterministic: identical input and identical settings always produce identical output, and formatting the output again changes nothing. The two main controls are indentation and the maximum line length. When a line exceeds that length, wrapping happens at structural points such as argument boundaries and around operators, never in the middle of a token or inside a string literal.

Good uses

  • Normalizing Swift copied from tutorials, Stack Overflow answers, or AI assistants before committing, so the git diff does not drown in unrelated whitespace changes.
  • Settling style disputes in code review: run the contested file through one configured formatter so spacing arguments become a one-time settings decision instead of a comment thread.
  • Checking a snippet's spacing when Xcode is not handy, such as on a non-Apple machine or while drafting a blog post with inline Swift examples.

Limits and checks

  • It parses before it formats, so a snippet with any syntax error produces no output at all. You cannot use it to clean up code that is still mid-edit, and a formatter error does not mean the formatting is wrong; it means the Swift is not valid yet.
  • 'Apple style' leaves real choices open: Xcode's editor defaults to 4-space indentation while Apple's own swift-format defaults to 2, and both are defensible. If the output looks wrong, check the indentation and line-length settings before concluding the tool is broken.
  • Formatting is cosmetic. Naming that violates the API Design Guidelines, force unwraps, overlong function signatures, and other judgment calls pass through untouched, so a perfectly formatted file can still be poor Swift. Reviewers should keep reading.

Common questions

Will the output match what Xcode produces?

Not necessarily. Xcode's editor is not a full formatter; it mostly reindents what you type, and its defaults differ from Apple's own swift-format (Xcode uses 4-space indentation, swift-format defaults to 2). Set this tool's indentation to match your Xcode preferences and the common cases will agree, but wrapping choices can still differ.

Does it rewrite my code, or only fix whitespace?

Only whitespace and line breaks. Identifiers, literals, comments, and semantics never change, and a string literal's contents are untouched. Formatting is idempotent: running the same settings twice returns the same text. The whole job happens in the page, so pasting proprietary code does not send it anywhere.

References and verification

The example and behavioral notes were checked against the browser implementation. Standards and primary references below define the relevant format, formula, or platform behavior.

Related Tools