Format C# with a lexer that actually knows C# — interpolated, verbatim and raw strings, decimal suffixes and generics pass through untouched, whitespace is the only thing that changes, and the output is verified token-for-token against your input before it is shown. Free, no sign-up — runs locally in your browser.
The C# formatting problem
Most online formatters are JavaScript beautifiers wearing a
dropdown. For C# that is not a cosmetic shortcoming; it is
corruption with good presentation. C#'s surface is full of
spellings a JS engine reads as something else: the
$ that begins an interpolated string, the
@ that begins a verbatim one, the m
that makes a literal a decimal, the angle brackets of a
generic type. A beautifier that does not know those rules
rewrites them — and hands you back a file that may still
compile while meaning something different, or not compile at
all. This formatter was built because the engine next door
failed that test on real code: it exists to do less, verifiably.
How to use this tool
- Paste the C#, upload a
.cs file, or drop one on the panel. With “Format as I type” on, the result updates as you edit. - Choose an indent — 4 spaces is the C# convention; 2 spaces and tabs are one click away.
- Press Format C#. Unterminated strings and unbalanced braces are reported with a line and column instead of being formatted over.
- If your code arrived on one line, it is expanded at braces and statement ends; multi-line code keeps its own lines and gets fresh indentation.
- Copy or download. The output was re-lexed and verified token-for-token against your input before it was shown to you.
What formatting changes — and what it does not
Changed: leading whitespace on every line, recomputed from
bracket depth; runs of blank lines collapse to one; one-line
input is expanded structurally, with short accessor lists
({ get; set; }) kept on one line as C#
convention writes them. Never changed: the spacing inside a
line, because in C# that spacing is load-bearing
(List<string>, $"…",
10m, @"…"); the contents of any
string, including the inner lines of multi-line verbatim and
raw strings, which are data, not layout; comments and
preprocessor directives keep their text and their lines. And
the guarantee behind all of it: the result is re-lexed and
must match the input token for token, or it is discarded.
Lexer-level, stated plainly
This is not dotnet format and does not pretend to
be: there is no compiler here, no semantic model, no style
rules about brace placement beyond the lines you wrote. It
will not find a type error, and a missing semicolon lexes
fine. What it is for is the everyday mechanical job — code
pasted from a doc, a diff, a generator, a chat — made readable
without risk: the class of formatter whose worst case is an
error message, never a silent edit. For a codebase, use your
project's real formatter in the build; for everything before
that, this one is safe to reach for.
Frequently asked questions
Why not just run the input through a JavaScript beautifier?
Because it damages C# — measurably, on ordinary code. Tested during this tool's development, js-beautify's JS engine prints an interpolated string as $ "Order {Id}…" (the $ detached), splits a decimal literal into 10 m (a different program), detaches @ from verbatim strings, and spaces generics out as List < LineItem >. Those are not style choices; they are token changes. This formatter is built the other way around: a C#-aware lexer first, whitespace-only changes second, and a token-for-token verification of the output before you ever see it.
What exactly does formatting change — and what does it never change?
It changes whitespace only: indentation recomputed from brace depth, blank-line runs collapsed to one, and one-line code expanded at braces and statement ends (a short accessor list like { get; set; } stays on one line, as C# writes it). It never rewrites the spacing inside a line — in C#, spacing is syntax: List<string>, $"…", 10m and @"…" all break if you touch them, so a line you wrote keeps its internal spelling exactly. It never renames, reorders, or merges anything.
Which C# string forms are understood?
All of them: regular strings, verbatim strings (@"…", including multi-line ones whose inner lines are content and pass through untouched), interpolated strings ($"…{expr}…", including verbatim-interpolated), and C# 11 raw strings ("""…""", including the $$""" form whose interpolations use doubled braces). Char literals, comments and preprocessor directives are lexed as what they are — a '{' inside any of them never disturbs the indentation.
Is this a compiler check? Will it find my errors?
No, and it does not claim to be. The check is lexer-level: unterminated strings, chars and comments, and unbalanced brackets, each with a line and column. It will not find type errors, missing semicolons, or a wrong variable name — a great deal of broken C# lexes perfectly. What it guarantees is the formatter's side of the bargain: the output says exactly what the input says, verified token for token, or you get an error instead of output.
How does the token verification work?
After formatting, the result is lexed again with the same lexer, and its token stream must equal the input's — same tokens, same order, same text. Indentation is whitespace, so it does not appear in the comparison; anything else that drifted fails the check, the formatted text is discarded, and the tool reports the failure rather than handing you altered code. It is the same bargain this site's JavaScript and TypeScript formatters make, and it is why the formatter can be conservative about spacing without being risky.
My file uses 2-space indentation. Is 4 still the default?
Four spaces is the default because it is the C# community convention (and what dotnet format produces), but the indent option offers 2 spaces and tabs, and the choice is saved with your draft in this browser. The formatter recomputes leading whitespace from brace depth, so switching a file from one convention to another is exactly the one-line-each change you would expect — nothing else in the file moves.
Dev