A base64-encoded substring shifts depending on where its bytes land inside the 3-byte chunk grid. To find it in a wild base64 blob you need all three alignment variants (offset 0, 1, 2). This tool emits them, optionally as a single regex with | alternation.
Switch the encoding to utf-16 le when feeding the input to PowerShell's -EncodedCommand — that's the wire format Windows expects.
Regex output uses plain capturing groups (a|b|c) — compatible with Palo Alto XQL / RE2 engines that don't accept (?:…).
runs entirely in your browser — nothing is sent anywhere
The offset-0 string covers bytes at positions where pos % 3 == 0 inside the outer base64. Offsets 1 and 2 cover the other two cases. Together they catch every occurrence regardless of where your bytes land. Leading/trailing characters affected by neighbouring bytes are trimmed automatically.
In regex mode, the input is parsed for these wildcard atoms: \w \W \d \D \s \S become .; \b \B are dropped; a bare . stays literal but . with a quantifier (.* .+ .? .{n} .{n,m}) becomes a wildcard. Quantifier counts are scaled by the base64 ratio — 1 source byte ≈ 1.33 base64 chars, so \w{17} in plaintext mode emits roughly .{21,25}, and in UTF-16 LE mode (2 bytes/char) roughly .{44,48}.
Each literal segment between wildcards is emitted as a three-alignment alternation (v0|v1|v2) using plain capturing groups for XQL / RE2 compatibility, so the match works at any base64 alignment even when wildcards split the input.