Extract ASCII and UTF-16 strings from any binary with byte offsets. Auto-flags IPs, URLs, registry keys, paths and base64. Runs locally, nothing uploaded.
Drop any file — an executable, a DLL, a memory dump, a firmware image, an unknown attachment — and extract every printable string it contains, with the byte offset of each one and automatic flagging of the strings that matter: IP addresses, URLs, email addresses, Windows and UNC paths, registry keys and base64 blobs. It is the browser equivalent of the Unix strings command, with the triage layer built in, and it runs entirely on your machine. The file is never uploaded, which is the whole point when the file is a malware sample you are not permitted to submit to a third-party service.
Pulling strings out of a binary is the first move in almost every static analysis workflow. Before disassembling anything, you want to know what the sample talks to, where it writes, what it names itself, and whether it is packed. All of that is usually visible in the strings, and it takes seconds rather than hours.
Every extracted string is matched against a set of regular expressions and tagged with the patterns it hits. These are the categories that turn a wall of text into leads:
| Pattern | Why it is worth flagging |
|---|---|
| IPv4 address | Hard-coded command-and-control endpoints, beacon destinations, internal ranges the sample expects |
| IPv6 address | The same, in the form that IPv4-only greps miss |
| URL (http, https, ftp) | Download stages, exfiltration endpoints, update servers |
| Email address | Exfil destinations, ransom contacts, or a developer address left in a build |
| Windows path | Drop locations and persistence directories — C:\Users\Public, %APPDATA%, \Temp\ |
| UNC path | Lateral movement and network share access |
| Registry key | Persistence via Run keys and services; HKLM, HKCU and the full-length forms are all matched |
| Base64 blob | Encoded payloads, configuration, or an embedded second stage — 40 or more base64 characters in a row is rarely accidental |
strings command’s conventional threshold. Raise it to 6 or 8 to cut noise on a large binary; drop it to 3 when you are hunting for short tokens and are willing to wade through fragments.http, Run, .dll, CreateProcess, VirtualAlloc, or the name of a product you expect the sample to impersonate.A few patterns are worth knowing before you start.
A very short string list on a large file usually means packing. A normal Windows executable of a few hundred kilobytes yields thousands of strings: imported function names, format strings, error messages, resource names. If a 2 MB binary produces two hundred strings, most of it is compressed or encrypted, and the small set you can see is the unpacking stub. That absence is itself a strong indicator.
Import names describe capability. Even without a proper PE parser, the imported API names show up as strings. VirtualAllocEx, WriteProcessMemory and CreateRemoteThread together are process injection. InternetOpenUrlA or WinHttpSendRequest mean network access. CryptEncrypt plus file-enumeration APIs suggests ransomware. IsDebuggerPresent is anti-analysis.
Offsets cluster meaningfully. Strings found close together usually come from the same section — a block of URLs at adjacent offsets is a configuration table, not a coincidence. Note the offset and open the file in a hex editor to see the surrounding structure.
Base64 hits are worth decoding. Copy the flagged blob into a base64 decoder; embedded configuration, PowerShell commands and second-stage payloads are routinely stored that way.
String extraction is a first pass, not an analysis. It finds only what is stored in the clear: anything XOR-encoded, RC4’d, stack-constructed one character at a time, or generated at runtime will not appear. Attackers know the technique and defeat it deliberately. It also produces false positives — the base64 pattern matches plenty of ordinary binary data, and any long random-looking run can trip it. Treat every flagged string as a lead to verify, not a conclusion.
The tool works on the whole file in memory, so very large images (multi-gigabyte memory dumps) are limited by your browser’s available RAM rather than by an upload cap.
No. The file is read as an ArrayBuffer in your browser and scanned there. Nothing is transmitted, which is what makes this usable for samples that cannot legally or safely be submitted to an online scanner.
strings command?The core extraction is the same idea, with two additions: UTF-16LE strings are scanned by default rather than requiring a flag, and every result is automatically matched against indicator patterns and offered with filtering, search and export. It also needs no toolchain installed, which matters on a locked-down analysis workstation.
Four to start — the conventional default. Increase it to reduce noise on large binaries; decrease it only when you are looking for something specific and short.
strings command misses?Because Windows stores most text as UTF-16LE, where every ASCII character is followed by a zero byte. A scanner looking for consecutive printable bytes sees each character as an isolated run and discards it. This tool runs a second pass on even offsets specifically to catch those.
Yes. Documents, firmware images, memory dumps, packet captures, disk images, unknown attachments — anything with bytes. The tool never inspects the extension.
No. Legitimate software contains URLs, registry keys and file paths constantly. The flags tell you where to look; establishing intent requires context.
Yes, as CSV or JSON, both including the offset, encoding, length, string value and any patterns matched.
That is usually packing or encryption. Check the ratio of file size to string count; if it is far off what a normal binary produces, the payload is compressed. An entropy analyzer will confirm it — high, flat entropy across the file is the signature.
Continue the triage with the file magic number checker to confirm what the file really is, the entropy analyzer to detect packing, the hex editor to inspect the bytes around an interesting offset, and the hash lookup to check the sample against known indicators.
String extraction scans binary files to find and display sequences of printable characters — revealing embedded text such as URLs, file paths, error messages, registry keys, API endpoints, encryption keys, passwords, and other human-readable data hidden within compiled executables, firmware images, and binary data files.
The Unix strings command and this tool perform the same function: they identify contiguous runs of printable ASCII or Unicode characters above a minimum length threshold (typically 4+ characters). This simple technique is one of the first steps in malware analysis, reverse engineering, and digital forensics because it quickly reveals what a binary "knows about" without executing it.
| String Type | Example | Intelligence Value |
|---|---|---|
| URLs | http://c2-server.evil.com/beacon | Command and control infrastructure |
| File paths | C:\Users\dev\malware\builder.py | Development environment details |
| Registry keys | HKLM\Software\Microsoft\Windows\CurrentVersion\Run | Persistence mechanisms |
| Error messages | "Failed to connect to port 443" | Functionality clues |
| IP addresses | 192.168.1.100 | Network targets or C2 servers |
| API function names | CreateRemoteThread, VirtualAllocEx | Suspicious API usage patterns |
| Encryption keys | Base64-encoded strings, hex sequences | Embedded secrets |
| Debug symbols | Function names, source file paths | Attribution and development info |
String extraction is the process of finding human-readable text sequences within binary files such as executables, firmware, or memory dumps. It is commonly used in malware analysis to find embedded URLs, file paths, error messages, and other indicators. Security researchers and forensic analysts use it to understand what a program does.
The tool extracts both ASCII and Unicode (UTF-16LE) strings from binary files. ASCII strings are single-byte character sequences, while Unicode strings use two bytes per character and are common in Windows executables. Both types are analyzed separately and can be filtered in the results.
The tool identifies strings matching patterns like IP addresses (IPv4 and IPv6), URLs, email addresses, file paths (Windows and UNC), registry keys, and Base64 encoded data. These patterns often indicate network communication, file operations, or obfuscated data that may be relevant during security analysis.
The minimum string length filter controls how short a sequence of printable characters must be to be included in the results. A length of 4 is the default, filtering out random byte sequences that happen to be printable. Increase it to reduce noise or decrease it to find shorter strings that might be meaningful.
Yes, all file processing happens entirely in your browser using JavaScript. Your binary files are never uploaded to any server. The tool reads the file locally using the FileReader API and processes it client-side. This makes it safe to analyze sensitive or proprietary files without privacy concerns.
Results can be exported in CSV or JSON format. The CSV export is useful for importing into spreadsheets or other analysis tools. The JSON export includes full metadata and is suitable for programmatic processing. Both formats include the offset, length, type, string value, and any detected patterns.
The offset shows the byte position within the file where each string begins, displayed in hexadecimal format. This information is useful when using a hex editor or debugger to locate the exact position of a string in the original binary file for further analysis.