# Compiler — Tips & Tricks

> Tricks for the Compiler: pick the right output style, the rule-based minifier limits, how it differs from Beautify, and combining with other tools.

Source: https://www.jpkc.com/db/en/tools/compiler/tips/

Back to the overview: [Compiler](https://www.jpkc.com/db/en/tools/compiler/) · Open the tool: [www.jpkc.com/tools/compiler/](https://www.jpkc.com/tools/compiler/)

The [manual](https://www.jpkc.com/db/en/tools/compiler/manual/) explains every feature, the [examples](https://www.jpkc.com/db/en/tools/compiler/examples/) show the workflows. This page is about what both assume: when which mode is the right one, where the engines have their quirks, and which task another tool handles better.

## Picking the right mode

- **Minified CSS from SCSS? Use `Compressed`, not the detour.** When your CSS comes from SCSS anyway, produce the compressed form directly in the `SASS/SCSS` tab via the **`Compressed` Output Style**. That's cleaner than "compile to `Expanded` first, then go to the `CSS` tab and minify," because the Sass engine handles the compression itself rather than forcing it afterwards with text rules.
- **Beautify and Minify are two directions of the same tab.** In `HTML`, `JavaScript`, and `CSS` you work on the same input either forwards (readable) or backwards (compact). That makes each tab a back-and-forth tool: beautify to edit, minify to ship.
- **For production JavaScript: think about `Drop console`.** `Mangle names` is on by default and shrinks reliably. `Drop console` is **off** by default — for real production code you usually want to tick it to clear out debug output.

## The engines and their quirks

- **SASS runs on LibSass, not Dart Sass.** [sass.js](https://github.com/medialize/sass.js/) covers the classic Sass feature set: variables, nesting, mixins, `@import`, functions like `lighten()`. The **modern module features** (`@use`, `@forward`, `sass:` modules) are not part of it. If you write code for this tool, stick to classic `@import` syntax — otherwise it won't compile.
- **No file system, no `@import` of files.** The engine runs in the browser without file access. It can't resolve external partials; the entire SCSS source must sit in the input editor.
- **The SASS engine loads only on the first compile.** Around 4 MB is pulled in once — so the first Compile click takes noticeably longer than the ones after it. That's intentional (the page loads faster without this module), not a hang.
- **HTML and CSS minify are rule-based, not a parser.** They work via text rules, not a full syntax tree. That's fine for normal code; in special cases it can overreach (see pitfalls). The **JS** minify, by contrast, uses [Terser](https://terser.org/), a genuine AST-based minifier — and is correspondingly robust.

## Pitfalls from practice

- **Whitespace-sensitive HTML when minifying.** `<pre>`, `<textarea>`, or elements with `white-space: pre` can lose whitespace through the rule-based HTML minify. Check the result when such regions are present, or minify only the non-critical parts. (In **Beautify**, `<code>` and `<pre>` are excluded — their content stays untouched there.)
- **CSS minify always removes comments.** Unlike the HTML tab, the `CSS` tab has no option to keep comments — even a license header `/*! … */` is dropped. If you need it, add it back after minifying.
- **Exotic CSS can confuse the rule-based minify.** Complex `calc()` expressions with meaningful whitespace or content inside `content: "…"` are candidates for unintended changes. When in doubt, double-check the result — or take the SCSS `Compressed` route, which uses a real parser.
- **`Mangle names` only renames local names.** Global APIs and exports stay unchanged — so there's nothing you need to "rescue," but don't be surprised if not every name gets shortened.
- **Output is read-only.** You can't edit the right-hand editor — it only shows the result. To keep working, use **Copy** or **Download**, or paste the output as new input.
- **Persistence is per browser, not per device.** Inputs are saved in LocalStorage (handy across reloads), but they live only in *this* browser. **Clear** deliberately removes a tab's saved state along with it.

## How it differs: when to reach for Beautify instead

The Compiler beautifies HTML, JavaScript, and CSS with the same library as the standalone **[Beautify](https://www.jpkc.com/db/en/tools/beautify/)** tool — so the plain indentation function is comparable. Reach for Beautify when you want to **deobfuscate** code (untangle squashed, deliberately unreadable code) or need finer formatting control. Stay with the Compiler when beautify is just one step alongside compile and minify — then you have everything in one interface.

## Combining with other JPKCom tools

- **[Playground](https://www.jpkc.com/db/en/tools/playground/)** — test compiled CSS in context with HTML and JavaScript, with live preview. A good next step after a `SASS/SCSS` compile.
- **[Source Viewer](https://www.jpkc.com/db/en/tools/source/)** — view longer source code (100+ languages) with highlighting when you want to compare result and original side by side.
- **[Color tools](https://www.jpkc.com/db/en/tools/colors/)** — generate color values and formats to drop into your SCSS as variables or straight into your CSS.
- **[Font tools](https://www.jpkc.com/db/en/tools/fonts/)** — work out typography values to feed into your stylesheet.

---

More context: the [overview](https://www.jpkc.com/db/en/tools/compiler/) for the big picture, the [manual](https://www.jpkc.com/db/en/tools/compiler/manual/) for every engine and option, and the [examples](https://www.jpkc.com/db/en/tools/compiler/examples/) for the step-by-step workflows. You can try all of it directly in the [tool](https://www.jpkc.com/tools/compiler/).