Sass @debug prints the value of a variable or expression while you develop—along with the filename and line number. This page covers syntax, inspecting any Sass type, how @debug differs from @warn and @error, and five compiled examples.
01
Print
@debug
02
Locate
File + line
03
Any value
Not just strings
04
Continue
CSS still ships
05
Vs warn
Inspect vs tip
06
Practice
5 examples
Concept
What Is @debug?
Official docs: sometimes it is useful to see the value of a variable or expression while you are developing your stylesheet. That is what the @debug rule is for: written @debug <expression>, it prints the value of that expression, along with the filename and line number.
Messages appear in the compiler / terminal / build log—not in the CSS file.
Compilation continues; CSS is still produced.
You can pass any Sass value, not just a string.
Printed representation matches meta.inspect().
Exact message format varies by Sass implementation.
💡
Beginner tip
Think of @debug as console.log for Sass. Use it while you figure out math, maps, and mixin arguments—then remove it before you ship.
Colors, maps, null, and strings each print clearly—same idea as meta.inspect().
Applications
🚀 Real-World Use Cases
Spacing math — confirm offsets before calc().
Design tokens — inspect maps while building a theme.
Helper functions — trace rem(), clamp, or color scales.
Generated CSS — verify loop keys and media widths.
Type confusion — print meta.type-of when a value misbehaves.
🧠 How Compilation Works
1
Hit @debug
Sass evaluates the expression at that point in the stylesheet.
Source
2
Print to the log
Filename, line, and the inspected value appear in the terminal.
Log
3
Keep compiling
Unlike @error, the build does not stop.
Continue
4
✓
CSS ships
Styles emit; debug lines stay out of the CSS file.
Watch Out
⚠️ Common Pitfalls
Leaving @debug in production — noisy logs; remove when done.
Using @debug as an API warning — prefer @warn for callers.
Expecting CSS output — debug never appears in the stylesheet.
Spam in loops — large maps can flood the terminal.
Confusing with @error — @debug never fails the build.
Pro Tips
💡 Best Practices
✅ Do
Label values: @debug "offset: #{$x}"
Debug intermediate calculations before CSS
Inspect maps/lists with direct @debug $map
Remove debug statements before merging
Use meta.type-of when types look wrong
❌ Don’t
Ship permanent @debug in shared libraries
Replace @warn / @error with debug prints
Assume every build tool shows debug the same way
Debug huge structures on every rebuild forever
Expect browsers to see @debug
Summary
Key Takeaways
Knowledge Unlocked
Five things to remember about Sass @debug
Inspect any value with file + line—compilation keeps going.
5
Core concepts
🔎01
Print
@debug value
Inspect
📄02
Locate
file + line
Log
📦03
Any type
like meta.inspect
Values
🔀04
Continue
CSS still emits
Build
✓05
Temporary
remove before ship
Dev
❓ Frequently Asked Questions
It prints the value of an expression along with the filename and line number so you can inspect variables and calculations while developing your stylesheet.
No. Like @warn, it continues compiling and still emits CSS. Only @error stops the build.
Yes. Official docs: you can pass any value. Sass prints the same representation as meta.inspect().
In the compiler / terminal / build log—not in the CSS file. Exact formatting varies by Sass implementation.
@debug is for inspecting values during development. @warn is for soft guidance to API users (deprecations, tips) and usually includes a stack trace meant for callers.
No. Remove or comment out debug statements before shipping so build logs stay clean. Prefer temporary checks while developing.
Did you know?
Official Sass docs note that @debug prints the same representation of a value as meta.inspect()—so maps, lists, and colors stay readable in the log.
@debug is your Sass console: print any value with a file and line, keep compiling, then remove the noise when you are done. Use @warn and @error when talking to API consumers instead.