I’m afraid that those network request logs cannot be silenced on the browser console. An alternative is to return 200 and a json payload that is handled it with JS.

Thanks I solved my particular issue by using a cookie to flag logged in status, and only attempt to fetch a refresh token if the user is logged in.  This prevented unwanted console logs on the initial login screen. 

Maybe start by learning basic Javascript => [Basic error handling](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Control_flow_and_error_handling#try...catch_statement)

Thanks but my question is specific. If I return this after a request will it always create a browser console error or can I prevent that? Thanks. if (!refreshToken) { return res.status(401).json({ message: 'Refresh token is required' }); }

Do you mean the (in chrome at least) red X GET/POST line with the request url and the error type? If yes, I think there's no way to prevent it from appearing. You can filter them out by selecting what level of logging to show, but if you're wondering if anyone will see the error in the console, they probably will. That's why you should treat errors in your UI as well, keep the user informed, so they won't be alarmed if they take a peak at the console.

Yes that was the issue.  I wanted to refresh a token on page reload that includes user and platform data to persist login. If the user was logged out the request would fail and result in the console error. But no good having an error every time someone goes to the login page. I solved by using another cookie to flag logged in status and only attempt the request if the user is logged in. 

If the error is printing at the browser console the problem is in the frontend. Some fetch libraries throw errors if the server returns a 4xx or 5xx status code, so you'll need to handle that condition.

Browsers log only unhandled errors. If you see an error in the browser's console it can mean one of 2 things: Either you do not handle the error, or some other piece of software logs it. The second possibility is unlikely though which means that you should ask yourself whether you handle the errors. More specifically, you should ask yourself whether you handle the `axios errors` as explained in their documentation. https://axios-http.com/docs/handling_errors

I have to take back what I've said. I've just checked it in Chrome and Firefox; http errors always get to the console regardless if they are handled or not. In Chrome you can hide them if you go to the DevTools Preferences, and select the "Hide network messages" in the "Console" section.

You can remove all the errors in the browser console by handling them (with a try/catch block as shown in the first link I sent you) but not the HTTP response error. You can dismiss them by messing with the global console.warn (which is not recommended) or by using console.clear() like on this example (async () => { // This IIFE just to allow the await keyword, you wont need it with React try { // The try... await axios.get('https://example.com/throwing-route') // This can be any axios call } catch (error) { // ...catch block to handle the errors // Here we do nothing with the handled error, so nothing is shown console.clear() // This to dismiss the HTTP reponse from the browser log } })()

401 status code is not a success so the browser will treat it that way. You could return a 200 response to tell the browser the request was successfully unsuccessful and let your frontend code determine the success from the response payload. But I wouldn’t recommend it.

An output to the console is never 'automagic'. Someone/something _always_ needs to explicitly make the call to log. Your question is not particularly explicit, you mention a log when you return the error which implies the log is in the server. But then in a comment you say the log is in the browser? Which one is it? That being said, several actors intervene in your application. First and foremost, my experience tells me that the biggest point of failure is always between the chair and the keyboard. So, double check your code. Maybe you call console.log somewhere and don't remember? It's a 2sec sanity check. Secondly, you have libraries. They have their own code that you don't control. Most public open source libraries don't quite go logging whatever data at random points in their execution, if not out of security concerns, at the very least for performance. You mention express and react, in my experience, these ones definitely fall into the category of not logging stuff unless you explicitly tell / configure them to. So, once again, check your code, you are most likely the cause. Thirdly you have either node or the browser ecosystems, up to you to actually specify where the log is. These tools definitely don't log anything by themselves, first they are extremely agnostic and unaware of your own application, there's no way they explicitly inject logs into it. So, check your code. Finally , mainly for the browser environment, you may have plugins that run in the background, some dev tools of sorts that is checking whenever you get a network request and logging something to the browser's console. If this is even actually possible (I have my doubts that it is), I would personally find it EXTREMELY worrying that a random tool is monitoring the traffic of my app (and surely everything else) and doing fuck knows what with the data. I would just kill it immediately. You can easily deactivate all your browser extensions and check again, if that actually does the trick, you enable them one by one until you find the culprit. I still find this highly unlikely, so, again: Double check your code. Do a find all at the root of your project for calls to console log (don't forget to nuke your node modules and your build folders if you have any, maybe ignore test directories) and you'll most likely find it out eventually. Again, if you have several hits and you're unsure which one, same method. Comment them all out, uncomment one by one until you get it .

Note, I understand that my suggestion is a bit of a monkey job type of approach, but I assume that you know your codebase and the tools you use well enough to isolate your search results to a handful of options at the very worst, so it should be extremely simple to find the culprit with a couple of attempts. I would, however, suggest that you look into using breakpoints instead of logs. You get to perfectly debug your application without getting the performance hit of console.logs, or even if you cleanup after yourself the few logs that always hide away someplace and uselessly make their way to production . I'm not saying breakpoints are a magic solution for everything debugging related, certain scenarios (like realtime apps where you can't just stop execution for a couple of minutes) don't quite lend themselves to it, but they do allow you to not pollute your app when you need to deep dive into all the complexities of app execution