It seems unlikely that all of these companies are properly sanitizing characters and after doing some research I think this could happening because of XSS auditors in Chrome/Firefox?
Chrome's XSS auditor does not actually render the payload harmless, it throws a warning preventing the user from accessing the page.
If you check the source code when you get a warning, you should see that the XSS payload is highlighted as seen in the example below.
From personal experience with participating and running bug bounty programs, you do not normally need to demonstrate an XSS auditor bypass in order for your report to be valid. In my opinion, it is not a good idea to rely on the browser's auditor, especially since not all browsers come equipped with an XSS auditor (e.g. Firefox) and new bypasses are found all the time.
Am I correct that in some cases the website isn't encoding my XSS payload and that the auditors themselves are making assumptions about my code and preventing an alert from firing? If so, how do I avoid this?
As stated above, Chrome's XSS auditor will only throw a warning. So if you see the warning shown above, you might actually have a valid XSS vulnerability.
[...] how do I find bypasses?
Most of the bypasses that you see online require a specific context for the payload to actually work. That being said, there have been universal bypasses in the past as seen in the Chromium issue tracker. Bypasses can be discovered via fuzzing, general experimentation, or purely by chance. On top of that, some bypasses are discovered by altering a previous bypass (See https://bugs.chromium.org/p/chromium/issues/detail?id=709365 and https://bugs.chromium.org/p/chromium/issues/detail?id=738017).
In future, what I recommend doing in order to make sure that the XSS auditor never kicks in while you are hunting, is to simply fire up Chrome using the
If you are interested in learning more about browser XSS filter bypasses, I highly recommend taking a look at "Browser's XSS Filter Bypass Cheat Sheet
" by Masato Kinugawa.