--- title: Stop Using console.log()! | daily.dev description: In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better. canonical: https://daily.dev/blog/stop-using-console-log/ og:type: article og:url: https://daily.dev/blog/stop-using-console-log/ og:title: Stop Using console.log()! | daily.dev og:description: In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better. og:image: https://media.daily.dev/image/upload/s--cy7mIPOp--/f_auto,q_auto/v1/recruiter-landing/5f899abd3172fd6897f8680d_ezgif_6_7a7c8616f587_e4a4ee7884?_a=BAMAMiB80 og:site_name: daily.dev og:locale: en_US article:published_time: 2020-10-16 article:modified_time: 2026-05-15T14:26:13.966Z article:author: Esaú Morais twitter:card: summary_large_image twitter:site: @dailydotdev twitter:creator: @dailydotdev twitter:title: Stop Using console.log()! | daily.dev twitter:description: In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better. twitter:image: https://media.daily.dev/image/upload/s--cy7mIPOp--/f_auto,q_auto/v1/recruiter-landing/5f899abd3172fd6897f8680d_ezgif_6_7a7c8616f587_e4a4ee7884?_a=BAMAMiB80 --- Whenever I see someone effectively debug JavaScript in the browser, they use the browser’s DevTool. Setting breakpoints and hopping over them. That, as opposed to sprinkling console.log() statements all around your code. In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better.  ## #1 Missing contextual information console.log() forces you to select which information to log before the debugging consciously. And what you display in the first place is not sufficient or even completely irrelevant sometimes. You usually don’t yet have any idea of what’s going on. Every time you launch your app, you go a step further, realizing you are still not logging the right information at the right time, wasting hours changing your statements, again and again, to display new information and hide irrelevant ones. #### Debugging Tip: - Display/watch any JS variable inline while debugging (function arguments, local variables, global variables, etc.). - Explore the call stack to get the complete context in which your problem appears. ## #2 Too much information Algorithms are usually designed to automate many small tasks, loops, and recursion being fundamental building blocks for this. Along with console.log(), it results in many lines displayed in front of you, i.e., a hard time coming to find the right information. #### Debugging Tip: - Create conditional breakpoints to pause the execution at the right time so that you can analyze what’s going on. - Watch custom JS expressions (variables, conditions, etc.) so that you don’t waste time to derive the same expression at each step of a loop. - Create a debug login addition to your standard application log to activate debug messages on-demand for the “domain” of interest (e.g., file, service, class, etc.). ## #3 Untrustworthy information Most of the time calling console.log() when the console is not yet active only results in the object being queued, not the output the console will contain. As a workaround, you will need to either clone the information or serialize snapshots of it. The rendering happens asynchronously (being throttled to rate-limit updates), as future interactions with the logged objects like expanding object properties in the browser console. #### Debugging Tip: - Asynchronous stack trace (now the default in Chrome) allows you to inspect function calls beyond the current event loop, just like context-aware travel in time to the originators of your asynchronous callbacks. ## #4 Altered code behavior The “standard” way to debug asynchronous code is to console log “1”, “2”, “3”, “4”, etc. i.e., all executed steps before the output you’re expecting until you get the right order. Consequently, you modify the code and, thus, the way it runs, leading to tracking unsteady behaviors really hard. After you finish debugging, you also have to remember to delete all the stray console logs in your code. #### Debugging Tip: - Part of debugging is not just inspecting code. It’s a process, inspect, change, and then continue debugging. If I spend a bunch of time setting up [breakpoints](https://developers.google.com/web/tools/chrome-devtools/javascript/breakpoints/?source=dailydev), will they still be there after I’ve changed my code and refreshed? Answer: [DevTools](https://developers.google.com/web/tools/chrome-devtools/javascript/reference#stepping/?source=dailydev) appears to do a pretty good job with that. To finish this article, I can mention [winston](https://github.com/winstonjs/winston/?source=dailydev) or [loglevel](https://github.com/pimterry/loglevel/?source=dailydev) as fairly good customizable loggers, but I prefer to use them for production-grade logs (information, warnings, errors, etc.). If you believe you cannot use the debugger when running your tests, consider reading [this article](https://peterlyons.com/js-debug/?source=dailydev) and other similar resources you might easily find on the internet. ‍ ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/og-image.png?v=a830cdf1","width":1200,"height":630},"sameAs":["https://twitter.com/dailydotdev","https://www.linkedin.com/company/dailydotdev","https://github.com/dailydotdev","https://www.instagram.com/dailydotdev"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","description":"Free, personalized developer news aggregator. Stay on top of software development news, AI coding tools, and web dev - curated daily from trusted sources.","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}},{"@type":"WebPage","@id":"https://daily.dev/blog/stop-using-console-log/","url":"https://daily.dev/blog/stop-using-console-log/","name":"Stop Using console.log()! | daily.dev","description":"In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better.","inLanguage":"en-US","isPartOf":{"@id":"https://daily.dev/#website"}},{"@type":"Article","@id":"https://daily.dev/blog/stop-using-console-log/#article","headline":"Stop Using console.log()!","url":"https://daily.dev/blog/stop-using-console-log/","datePublished":"2020-10-16","dateModified":"2026-05-15T14:26:13.966Z","isPartOf":{"@id":"https://daily.dev/#website"},"publisher":{"@id":"https://daily.dev/#organization"},"mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/blog/stop-using-console-log/"},"description":"In this article, I will explain four reasons why you should stop using console.log() and the best tips to make it different, professional, and better.","image":{"@type":"ImageObject","url":"https://media.daily.dev/image/upload/s--cy7mIPOp--/f_auto,q_auto/v1/recruiter-landing/5f899abd3172fd6897f8680d_ezgif_6_7a7c8616f587_e4a4ee7884?_a=BAMAMiB80"},"author":{"@type":"Person","name":"Esaú Morais","url":"https://app.daily.dev/emmorais"},"potentialAction":{"@type":"ReadAction","target":"https://daily.dev/blog/stop-using-console-log/"}},{"@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev/"},{"@type":"ListItem","position":2,"name":"Blog","item":"https://daily.dev/blog/"},{"@type":"ListItem","position":3,"name":"Webdev","item":"https://daily.dev/categories/webdev/"},{"@type":"ListItem","position":4,"name":"Stop Using console.log()!","item":"https://daily.dev/blog/stop-using-console-log/"}]}]} ```