Search code examples
google-developers-consolebrowserstackcharles-proxy

Charles Proxy vs Developer Console vs Browserstack


It seems that more developers are using Charles Proxy nowadays, but I can't beg to differ what are the advantages or what you can do with Charles that you can't do with others like Chrome Developer Console or browser stack.


Solution

  • Debugging proxies like Charles Proxy, HTTP Toolkit and Fiddler all have a few features that browser developer tools don't:

    • They can capture traffic from non-browser sources, like mobile devices and desktop applications.
    • They can capture traffic from multiple tabs or other sources all in one place, so you can see the traffic from your web app and the backend traffic between your microservices all in one place.
    • They can capture traffic that the browser doesn't show - e.g. the browser's own requests for internal browser services, or safebrowsing checks, or CORS requests that don't appear in dev tools.
    • They include lots options to rewrite or reredirect traffic (usually with both custom rules to automatically mock responses and with breakpoints to manually edit traffic)
    • They usually offer more advanced traffic filtering and inspection, e.g. more powerful tools for finding certain requests, for inspecting more formats of request & response body, for understanding compression and caching behaviour, for validation of headers or even for validation of recognized request parameters with specific known APIs.

    That said, there's a few unique benefits of browser tools:

    • There is zero setup and no separate applications required.
    • You immediately get the exact traffic from a single page with no extra noise from anywhere else.
    • They can use metadata from the browser's internal state, e.g. to show which line of JS sent a specific request, or to show requests that failed before any connections were made (due to CORS, mixed content, or many other browser restrictions).