JavaScript Comment Remover

The comments people regret removing are the ones that explain why. A note recording which browser bug a workaround exists for, why a value is 250 rather than 200, or which upstream issue makes an obvious refactor unsafe cannot be recovered from the code itself — someone will eventually delete the workaround and reintroduce the bug. Comments that restate what the next line does are different; those go stale and add noise. If you are stripping comments from a file, keep the annotated version somewhere, because that is the copy that holds the reasoning.

Be careful stripping JSDoc from a library. Those blocks are consumed by tooling: editors read them to provide autocomplete and inline documentation, TypeScript can typecheck plain JavaScript from JSDoc annotations, and documentation generators build their output from them. Removing them does not change runtime behaviour, but it does remove the type information and editor hints that consumers of the code rely on — so strip JSDoc from application code if you like, and leave it in anything other people import.

Because the characters that start a comment are legal almost everywhere else. A URL in a string contains //, a regular expression can contain /* , and template literals can contain both. A naive find-and-replace will happily destroy a working program by cutting from inside a string to the end of a line. Comment removal has to track whether it is currently inside a string, a template literal, or a regex literal, which is why doing it with a text editor macro so often produces subtly broken code.

Minifying removes comments and also collapses all the whitespace, giving you one dense line. This removes only the comments and leaves your line structure and indentation exactly as they were, so the result is still readable. That is what you want when the goal is tidying rather than compressing — stripping a generator's boilerplate JSDoc, removing commented-out experiments before a handover, or preparing a clean snippet for documentation.

For anything running in a browser, yes. Client-side JavaScript is downloaded as source, so every comment in it is public and adds to the file size. This catches people out: a commented-out API call, a note naming an internal system, a TODO referencing an unreleased feature, or a credential someone left in while debugging are all readable by anyone who opens the file. Treat browser-side comments as published text.

Your build already does it — every production minifier removes comments as a matter of course, so there is no need to do it by hand for a bundled app. Keep the comments in your source, where they explain the things the code cannot. The exception is licence and attribution banners in third-party code, which many licences require you to preserve even in minified output.

No. Everything runs in your browser as JavaScript — your code is never uploaded, never logged, and never sent to a server. You can verify that by watching the Network tab in devtools while you work, or by disconnecting from the internet after the page loads and confirming the tools still function. Nothing you paste is executed either; it is only ever parsed as text.