Filter Android logcat in the browser

How is a logcat line structured?

threadtime looks like: 09-02 12:01:03.221 1234 1250 I MyTag: message. PID and TID are numeric; level is V/D/I/W/E/F/S; the tag is a short component name. A filter is a pipeline of predicates over these fields plus the message string.

How does in-browser filtering avoid uploading the dump?

You drop a .txt or paste into a textarea. The string lives in a JS heap. Split on \n, map to records, and filter. Export is another Blob. Compare that to adb logcat | curl — which is an exfiltration path with extra steps.

const THREADTIME =
  /^(\d{2}-\d{2}\s\d{2}:\d{2}:\d{2}\.\d+)\s+(\d+)\s+(\d+)\s+([VDIWEFS])\s+([^:]+):\s?(.*)$/;
const rec = line.match(THREADTIME);
if (rec && rec[4] === "E" && rec[5] === "OkHttp") keep(line);

How do you write performant regex for log filters?

Anchor patterns. Do not start with .* if you can start with a tag. Prefer [A-Z_]+ over (.+). Reuse one compiled RegExp. For millions of lines, batch in requestIdleCallback or a worker so the page stays interactive.

What secrets show up in logcat?

Authorization headers, deep-link query strings, SQL, and clipboard debug lines. Filter first, then share a slice. If you must attach logs to a ticket, run the same dump through a local redactor mindset: drop lines matching token= and Bearer.

When should you use a full log analyzer instead?

When you need histograms, crash clustering, or multi-file correlation. Those can still be client-side. The log-file analyzer on this site is the sibling for mixed formats; regex tester is where you prototype the pattern before applying it to 40 MB of logcat.

Frequently asked questions