YARA Syntax Viewer
Break a YARA rule into its meta, strings and condition sections.
Paste a rule on the left.
How it works
A YARA rule is three sections and a header, and the interesting part is almost always the relationship between two of them: which of the strings the condition actually reads. This takes the rule apart and states that relationship explicitly.
Declared is not the same as used
A string that no condition mentions is not an error. YARA compiles the rule and ignores the string, with no warning — so a rule that looks like it matches on four indicators quietly matches on three. It is an easy state to reach by editing a condition and forgetting the strings section, and an easy one to miss by eye in a long rule. Every declared string is marked used or unused here.
Why the brace counting is not naive
Three constructs put braces inside a rule body: hex strings are written in braces, and both text strings and
regular expressions can contain one. Counting braces without tracking literals ends a rule early on
$a = "}". What makes this tractable is that YARA spells integer division \ rather
than /, so a / always opens a regular expression and never has to be guessed at.
What it does not do
It does not compile the rule, evaluate the condition, or run anything against a file. Module expressions such as
pe.number_of_sections are shown as written and not resolved — knowing whether one is valid means
knowing that module's exports, and asserting that from memory is how a viewer starts telling people their correct
rule is wrong.
Example
The first sample is a complete rule: one import, four meta entries, and all three string forms — a hex signature, two text strings with modifiers, and a regular expression — read by a condition that uses every one of them.
The second is the same rule with a single change. $marker is still declared and the condition no
longer mentions it. Nothing about the rule looks wrong, and it compiles; the viewer is what tells you it now
matches on one indicator fewer than it appears to. Both rules are written for this page and name a fictional
family — they are illustrations of syntax, not detection content.
Frequently asked questions
What does “unused string” mean, and is it an error?
It means the strings section declares an identifier the condition never refers to. It is not an error — YARA compiles the rule and ignores that string without warning — which is exactly why it is worth surfacing. A rule that appears to match on four indicators is matching on three, usually because a condition was edited and the strings section was not.
Does it handle hex strings and regular expressions correctly?
Yes. Braces inside a hex pattern, a text string or a regular expression are tracked as part of the literal rather than as rule structure, so a rule containing $a = "}" is read correctly rather than ending early.
Does it check that my condition is valid?
No. It reports three things it can decide from the rule’s own text: strings declared but unused, a condition referring to a string that was never declared, and a missing condition. Anything needing the compiler’s semantics — operator types, module exports, offset arithmetic — is out of scope and is shown as written.
Is the rule sent anywhere?
No. Parsing happens in your browser and the rule never leaves it. There is no endpoint behind this page to send it to.
Related tools
YARA Rule Formatter
Reformat a YARA rule to consistent indentation and section order.
LocalSigma Syntax Viewer
Read a Sigma detection rule as structured logsource and detection blocks.
LocalSTIX Viewer
Read a STIX 2.1 bundle as structured objects instead of raw JSON.
LocalSigma Rule Formatter
Reorder a Sigma rule’s top-level keys to the conventional sequence.
LocalATT&CK Technique Lookup
Find a MITRE ATT&CK technique by ID or name from a bundled dataset.
LocalHash Identifier
Narrow an unlabelled hash down to the algorithms that could have produced it.
Local