js-beautify: a formatter for ugly, packed and obfuscated JavaScript

What js-beautify does that a style linter does not

The README describes the project as a beautifier that will "reformat and re-indent bookmarklets, ugly JavaScript, unpack scripts packed by Dean Edward's popular packer, as well as partly deobfuscate scripts processed by the npm package javascript-obfuscator." That sentence is the whole pitch, and it separates js-beautify from tools whose job is enforcing a house style on code a human wrote.

The audience follows from that. Someone who pastes a minified bundle into an editor and wants to read it. Someone who receives a script with single-letter identifiers and wants the control flow back. Someone maintaining a build pipeline who needs a formatter callable from Node or Python without pulling in a full toolchain. The repository topics list css, html, javascript, nodejs and python, which matches the three languages and two runtimes the README documents.

The project is not a linting framework and it does not check anything. It takes a string of code and returns a differently formatted string. Whether the result is correct is not something it verifies.

Three languages, two runtimes, one set of option names

The repository has separate js/ and python/ directories, and package.json points its bin entries at js/bin/js-beautify.js, js/bin/css-beautify.js and js/bin/html-beautify.js. The Python side is published as two packages, jsbeautifier and cssbeautifier, and the README is explicit that the Python version "can only reformat JavaScript. It does not work against HTML or CSS files." If you need HTML from Python, the README does not offer a path.

The option naming is consistent across surfaces. The README states that configuration option names are the same as the CLI names with underscores instead of dashes, so --indent-size 2 --space-in-empty-paren becomes { indent_size: 2, space_in_empty_paren: true } in library calls. That single rule covers the CLI, the Node library and the browser functions, and it is the most useful thing to memorise about the project.

package.json lists editorconfig and config-chain as dependencies, and the repository root contains a jsbeautifyrc file, so configuration can come from files rather than only from flags. The README does not document the precedence order between an .editorconfig file, a jsbeautifyrc file and command-line flags, so if you rely on more than one source, test the combination rather than assuming.

Installing js-beautify and beautifying a first file

The Node install is global and gives you the js-beautify executable. The README shows the beautified result going to stdout unless you configure otherwise, so redirecting it is the normal way to write a file.

npm -g install js-beautify
js-beautify foo.js

Run against a minified file, the command prints the reformatted source to your terminal. To keep it, redirect: js-beautify foo.js > foo.pretty.js.

For library use, install locally and require the language-specific entry point. The README gives this shape, where the first argument is the code string and the second is the options object.

var beautify = require('js-beautify/js').js,
    fs = require('fs');

The README's own browser example passes a JSON string through the same function, with options written in the underscore form:

const options = { indent_size: 2, space_in_empty_paren: true }
const dataObj = {completed: false,id: 1,title: "delectus aut autem",userId: 1,}
const dataJson = JSON.stringify(dataObj)
js_beautify(dataJson, options)

The documented output expands the object across lines with two-space indentation and a trailing comma after the last property. Note that the README calls this beautifying a JSON string through the JavaScript beautifier, not a dedicated JSON mode.

The Python route is a separate install and a separate capability set:

pip install jsbeautifier
pip install cssbeautifier

This project no longer supports Python 2, per the README. For a browser page, the README lists cdnjs script tags for beautify.js, beautify-css.js and beautify-html.js at version 2.0.3, plus minified variants, and states that embedding them exposes js_beautify, css_beautify and html_beautify as global functions. The README also carries a disclaimer that these CDNs are free services with no uptime or support guarantees, which is worth reading before you put one in a production page.

Where js-beautify stops being the right tool

Deobfuscation is partial, and the README says so with the word "partly". A beautifier can restore indentation and line breaks. It cannot recover a variable's original name, and it cannot undo control-flow flattening or string-array indirection that an obfuscator applied deliberately. If the code you have was run through javascript-obfuscator, expect readable structure and unreadable identifiers.

Packers are a similar story. The README mentions unpacking scripts packed by Dean Edward's packer, which is a decoding step the project implements. That is not the same as general minifier reversal, and the README makes no claim about arbitrary bundlers.

The Python package is the sharper limitation. Anyone who installs jsbeautifier expecting it to handle an HTML template gets nothing, because the README states the Python version reformats JavaScript only. Python users who need CSS install cssbeautifier as a second package, and there is no Python equivalent for HTML in the README at all.

Finally, the README opens with a section titled "Contributors Needed" and states that existing owners "have very limited time to work on this project currently." That is the project describing its own maintenance situation. It does not mean bugs go unfixed, but it does mean a pull request you file may sit. The last push to the repository was on 2026-09-14, and the most recent release listed is v2.0.3 from 2026-07-03.

js-beautify versus Prettier: different jobs, different defaults

Prettier is the obvious comparison and the two tools are not interchangeable. Prettier parses your source into an AST and prints it back with a fixed, opinionated style, and it treats configuration as something to minimise. js-beautify works closer to the token stream: it re-indents and re-wraps what is there, and its option surface is large and exposed, which is why the README can document a mapping between CLI flags and library keys as a general rule.

That difference shows up in output. A Prettier run over a file will change line breaks in ways you did not ask for, because that is the design. A js-beautify run is more likely to preserve the shape of what you gave it and adjust whitespace, which is what you want when the input is a bundle you are trying to read rather than code you own.

It also shows up in integration. Prettier is a JavaScript tool. js-beautify ships a Python package, and the README treats Python as a first-class install path alongside npm. If your pipeline is Python and you want to reformat JavaScript without a Node runtime, js-beautify has an answer and Prettier does not.

Where Prettier wins is consistency across a team. js-beautify gives you many knobs, and many knobs means many ways for two developers to produce different output. If your goal is a single canonical format enforced in CI, js-beautify is the wrong shape of tool.

Licence, upgrade cost and what a version bump involves

The repository is MIT licensed, and package.json repeats that under the license field. MIT is permissive: you can use, modify and redistribute the code, including in closed products, provided the copyright notice and permission notice travel with it. That is a general description of the licence text, not legal advice, and if you are embedding the library in a distributed product you should read the LICENSE file in the repository root yourself.

The dependency list is small. package.json lists config-chain, editorconfig, glob, js-cookie and nopt as runtime dependencies, with diff and serialize-javascript pinned under overrides. A small dependency tree lowers the cost of a version bump, though the overrides entries are worth noting: they exist to force specific versions of transitive packages, which is a maintenance obligation someone has to revisit.

The version history in the repository shows a long gap between the 1.15.x releases in February 2025 and v2.0.3 in July 2026. A major version boundary means the upgrade is not a drop-in patch, and the README does not document a migration path from 1.x to 2.x. If you are on 1.15.3, check the CHANGELOG.md in the repository root before moving, because that is where the project records what changed.

The Node engine requirement is >=14 in package.json, and the browserslist field is set to "ie 11", which tells you the browser build is still transpiled for a very old target. That is a deliberate compatibility choice, and it is also a reason the shipped web bundle may be larger than you expect.

Editorial conclusion

Adopt js-beautify when you need a formatter that runs as a Node CLI, a Python package or a plain script tag, and when you are dealing with packed or partly obfuscated code that a style-focused formatter will not touch. Do not adopt it expecting a project with a large active maintainer group: the README asks for contributors in its opening section, and the last push to the repository was on 2026-09-14. Before committing, verify which of the three binaries you actually need (js-beautify, css-beautify or html-beautify), confirm that your Node version satisfies the engines field of >=14, and run the formatter over a representative sample of your own files to see how its output differs from what your team already accepts.

Frequently asked questions

Official sources

1. beautifier/js-beautify on GitHub
2. License: MIT
3. Project website
4. README
5. Releases