We traced these messages to the exact lines in the analyzer's JavaScript. One bad request is enough for it to reject the whole file, even when the HAR is otherwise valid.
Unknown base64 encoding at char: [
The most common one, and it comes from sanitized HARs. Sentry, HAR sanitizer tools and redaction scripts swap a large body for a placeholder such as [text/javascript redacted], but leave "encoding": "base64" and the original size (e.g. 3,533,145). The analyzer base64-decodes every non-image body while loading, reaches [ and gives up on the whole file.
Fix: drop the base64 flag only where the text isn't valid base64, and set size to the placeholder's length. Real images and fonts keep their encoding.
Unable to process the HAR file: SyntaxError…
The file isn't valid JSON. Usually there's a UTF-8 byte-order mark at the start, trailing commas from a hand-edited or scripted export, or the file was cut off because the browser or a size limit stopped it partway through.
Fix: strip the BOM, remove trailing commas and cut a truncated file back to the last complete request, then close the JSON properly.
URIError: URI malformed
A response labelled application/x-www-form-urlencoded contains a stray % (like 100%) or a truncated escape. The analyzer runs decodeURIComponent() on it and throws.
Fix: relabel just that body as text/plain. The text itself is untouched.
No log entries found in the file.
Google needs log.entries with at least one request. Some tools write a bare array, wrap the HAR in {"har": …} or put entries at the top level.
Fix: move the entries back under log. If the recording really has zero requests, record it again (see below).
Silent failures: blank page or a frozen spinner
A null entry, a numeric mimeType or method, a header whose name is a number, or "timings": "fast" all throw deep inside the loader without a readable message.
Fix: drop null entries, convert these fields to strings or numbers, and add missing request, response, content, timings and cache objects.
Invalid dates and non-numeric timings
A startedDateTime of "bad" or an epoch number, or time: "n/a", breaks the waterfall and sorting, and trips up other HAR viewers too.
Fix: epoch values become ISO 8601 and invalid ones get a valid timestamp. Timings and sizes are converted to numbers, with -1 meaning "not available" as the HAR 1.2 spec says.