JavaScript Formatter
Format JavaScript locally without running it and control indentation, brace placement, preserved newlines, and preferred line wrapping.JavaScript formatting result
{{ workflowFeedback }}
{{ formattedSource }}
{{ downloadStatus }}
The chart renderer is unavailable. Exact byte counts remain available in the formatting ledger.
| Signal | Value | Meaning | Copy |
|---|---|---|---|
| {{ row.label }} | {{ row.display }} | {{ row.detail }} |
Dense JavaScript slows down the part of development that depends on human judgment. A browser can read a one-line file, but a reviewer needs to see blocks, expressions, comments, and control flow before deciding where a bug or risky change may sit.
Beautification rebuilds that visual structure from the source text. Indentation shows nesting, brace placement follows a chosen style, and optional line wrapping creates break opportunities around long expressions. Existing line breaks can remain as hints or be normalized when inherited formatting is more distracting than useful.
Common uses include inspecting a minified snippet, preparing copied code for a review, comparing two versions, or making a generated file readable enough to diagnose. The formatted text may be longer in bytes and lines because readability adds whitespace; that increase says nothing about runtime speed or production quality.
- Formatting changes layout, not variable names, program design, or intended behavior.
- A preferred wrap width is a soft opportunity, not a promise that every line will fit that width.
- Readable output is not proof that the program parses, passes a linter, or behaves correctly when run.
Treat the result as a review copy. Keep the original under version control, then use the project's parser, linter, tests, and runtime for the checks that formatting cannot provide.
How to Use This Tool:
Start with the style expected by the destination project and change only the options that help the current review.
- Paste JavaScript or load one supported text or script file into JavaScript source. The UTF-8 source limit is 256 KiB.
- Choose two spaces, four spaces, or tabs for Indentation. Select collapsed, expanded, or expanded-closing Brace style to match the codebase.
- Leave Preferred wrap off when long lines should remain intact, or choose 80, 100, or 120 characters to allow wrapping at safe opportunities.
- Keep Existing newlines on when source spacing carries useful grouping. Turn it off when you want the formatter to normalize those breaks.
- Review Formatted JavaScript and the formatting ledger, then run the result through the destination project's syntax and test checks before use.
Interpreting Results:
A formatted result means the beautification pass returned text for the selected options. It does not mean the source was executed or accepted by a JavaScript engine. If a damaged or unusual fragment still produces output, verify it with the parser used by the target application.
Compare source and formatted line and byte counts as footprint information only. A larger formatted file normally reflects indentation and line breaks; it is not evidence of added logic. The ledger is the clearest place to confirm the exact indentation, brace, wrap, and newline policy used for the result.
Technical Details:
JavaScript beautification reads lexical and structural cues to decide where whitespace can be inserted or removed. The transform is intentionally tolerant, which is useful for incomplete snippets but also means it should not be mistaken for a standards-complete syntax check.
Transformation Core:
| Decision | Applied rule | Important limit |
|---|---|---|
| Indentation | Nested output uses two spaces, four spaces, or one tab per level. | Changing indentation does not change the source's identifiers or expressions. |
| Braces | Collapse keeps opening braces with the statement; expanded styles move selected opening or closing braces. | The formatter follows supported structural cues rather than a project-specific style configuration. |
| Existing breaks | Preserve mode retains up to two consecutive source line breaks where supported; normalize mode discards those hints. | Comments and special constructs can still require their own line placement. |
| Preferred wrap | A nonzero width allows breaks near 80, 100, or 120 characters. | The width is soft because some tokens and expressions cannot be split safely. |
| Output text | Line endings become Unix line feeds and the result ends with a final line feed. | Byte counts use UTF-8 and may rise after whitespace is added. |
The source is passed to a formatter with string unescaping disabled, so quoted escape sequences are not deliberately rewritten into different characters. JSX-like syntax is accepted on a best-effort basis. Template extensions, proposals, embedded languages, and partially invalid fragments still require the parser used by the destination project.
No runtime values, imports, network calls, side effects, or test outcomes are evaluated. Those facts become knowable only when the code is parsed and executed in an appropriate environment.
Privacy Notes:
JavaScript source is formatted in the browser and is not uploaded or executed by the formatter. Sensitive code can still enter browser history, backups, the clipboard, or a downloaded file through ordinary use, so handle the result according to the project's source-control and data rules.
References:
- js-beautify formatter and option reference, js-beautify project.