JPKCom DB

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.

Back to the overview: Compiler · Open the tool: www.jpkc.com/tools/compiler/

The manual explains every feature, the 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 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, 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 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 — test compiled CSS in context with HTML and JavaScript, with live preview. A good next step after a SASS/SCSS compile.
  • Source Viewer — view longer source code (100+ languages) with highlighting when you want to compare result and original side by side.
  • Color tools — generate color values and formats to drop into your SCSS as variables or straight into your CSS.
  • Font tools — work out typography values to feed into your stylesheet.

More context: the overview for the big picture, the manual for every engine and option, and the examples for the step-by-step workflows. You can try all of it directly in the tool.