JPKCom DB

Compiler — Tips & Tricks

Tricks for the Compiler: pick Output Style and Syntax wisely, modern Sass with @debug, cautious minifiers, and when the Beautify tool fits better.

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 squeezing it out of finished CSS afterwards.
  • 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). Use output as input turns that into a chain without any copy-pasting: beautify, take over the output, edit on the left, minify. Each takeover is a single undo step.
  • Leave the Syntax on Auto-detect. Detection tells SCSS from indented Sass by braces and semicolons outside strings and comments. If you pin a syntax, it sticks for your next visit too — and SCSS code then fails at its first { while Indented (.sass) is still selected. In that case the error message points you to Auto-detect.
  • 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 Dart Sass — write modern Sass. Dart Sass (opens in a new tab) understands the module system with @use, sass:math, and sass:color. Use math.div() and color.adjust() as the sample snippet does; when Dart Sass flags older code with the Deprecation: prefix, the message list below the editors shows you, line number included, where to start.
  • @debug beats guessing. Print intermediate values of variables or functions with @debug — they appear in the message list, not in the CSS. That way you can check a calculation without polluting the output.
  • No file system, no @use or @import of your own files. The engine runs in the browser without file access. It can't resolve your partials; the entire SCSS source must sit in the input editor. The built-in sass: modules aren't affected.
  • The Sass engine loads only on the first compile. Around 0.9 MB (gzip-compressed) is pulled in once — so the first Compile click takes a little longer than the ones after it. That's intentional (the page loads faster without this module), not a hang.
  • HTML and CSS minify are deliberately cautious. They only remove whitespace and comments where that doesn't change the result, and leave strings (except for the sequence ;}, see the manual), <pre>, <textarea>, and <script> untouched. They don't shorten values or merge rules. The JS minify, by contrast, uses Terser (opens in a new tab), a genuine AST-based minifier that also rewrites code.

Pitfalls from practice

  • The HTML minify doesn't know about white-space: pre set in CSS. <pre>, <textarea>, and <script> survive the minify character for character. An ordinary element that only gets white-space: pre from your stylesheet is invisible to the routine, though — its whitespace collapses to a single space like everywhere else. Put such content in a <pre> or check the result. (In Beautify, <code> and <pre> are excluded — their content stays untouched there.)
  • Write license comments as /*!. CSS comments of the form /*! … */ always survive the CSS minify, even with Remove comments (minify) ticked — and likewise inside <style> blocks during an HTML minify. If you want to keep all comments, untick Remove comments (minify) in the CSS tab.
  • <style> comments and the HTML minify. During an HTML minify, embedded <style> blocks go through the CSS minifier and lose their regular comments — regardless of whether Remove comments is ticked in the HTML tab. If you need a comment there, write it as /*! … */.
  • 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 Use output as input, Copy, or Download.
  • Plan your download names. If you load your file via Upload file instead of pasting it, the download takes over its name (theme.scss → theme.css, after a minify theme.min.css). The tool forgets that name when you reload the page; after that the download is called styles, index, or script again.
  • Persistence is per browser, not per device. Inputs and options 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 and asks first if the editor holds your own code; an accidental Clear can be undone with Ctrl+Z in the input editor as long as the page stays open.

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 unpack P.A.C.K.E.R.-packed or URL-encoded JavaScript, or when you need finer formatting control — the hint texts in the HTML, JavaScript, and CSS tabs link straight to it. 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 and the same Dart Sass engine. 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.