File automation is most useful when it captures decisions you already make. If every invoice PDF belongs in one folder, screenshots use a predictable name, or old project exports need review, a clear rule can replace repetitive selection and dragging. The challenge is to automate enough to save time without hiding why a file matched.
FileJuggler.online lets you build metadata rules in a compatible desktop browser. You select a folder, combine conditions, choose actions, and preview the complete plan before anything changes. The browser handles local access; files are not uploaded to an application server for analysis. This guide explains how to design reliable rules for names, extensions, sizes, dates, and paths.
Start with one sentence that describes the rule
Write the intended decision in plain language before touching the rule builder. A useful sentence might be: “Move PDF files with invoice in the name into Documents/Invoices.” Another could be: “Copy JPG and PNG images modified this year into Project/Review.” If the sentence is hard to explain, the rule will probably be hard to verify.
Identify the condition, action, and destination. Conditions decide which files match. Actions say whether to move, copy, rename, create a folder, or place a file in a review-oriented trash folder. The destination must remain inside the selected root. Rule order determines which decision is considered first, and Stop after match controls whether later rules can add more actions.
Begin with a small disposable folder containing matching and nonmatching examples. A rule that works on three carefully chosen files is easier to understand than one first tested against ten thousand mixed items. Once the preview matches your sentence, expand the scope.
Choose metadata conditions you can trust
Filename rules can use equality, containment, starts with, ends with, or other supported comparisons. They are helpful when a stable naming convention carries meaning, such as `invoice`, `screenshot`, or a project code. Avoid relying on temporary download names or inconsistent abbreviations unless the preview lets you review every exception.
Extension conditions identify formats from the filename suffix. They are case insensitive, so PDF and pdf belong together. An extension does not prove content, and compound names normally use the final suffix. Size rules compare actual file size using the selected unit. Modified-date rules use filesystem modification metadata, which may change when a file is copied or edited and should not be confused with creation date.
Path conditions use the relative location inside the selected folder. They can preserve project context or limit a rule to a known subfolder. No condition reads document text, recognizes images, opens archives, or asks an external AI service to infer private meaning. Predictable metadata keeps the result explainable.
Combine conditions with AND and OR
Use AND when every condition must be true. The invoice example uses extension equals PDF AND filename contains invoice. A large-video rule might require category video AND size greater than a threshold. AND reduces the match set and is a good default for rules that should be specific.
Use OR when any condition is enough. A screenshot rule might match names starting with `Screenshot` OR `Screen Shot`. A document rule might match PDF OR DOCX. OR broadens the set, so review it carefully and avoid mixing unrelated meanings simply to reduce the number of rules.
Nested groups let you combine both. You can require extension PDF AND a name containing either invoice OR receipt. Build the inner OR group for the two name terms, then combine that group with the PDF condition using AND. Read the completed tree aloud as a sentence. If the logic does not sound like the original intent, simplify it.
Put specific rules before general rules
Rule priority matters when one file can match several conditions. Suppose an invoice PDF matches both the specific invoice rule and a general Documents rule. Place the invoice rule first. If the file should receive only the invoice action, enable Stop after this rule matches. The general rule will then handle other documents without redirecting invoices again.
Use priority controls to make the list read from narrow exceptions to broad defaults. Add a final catch-all only when its destination is truly useful. Leaving an unmatched file in place is often safer than sending it to a vague folder that you will never review.
Create safe destination paths and rename templates
Destinations are relative to the selected folder. Use simple names such as `Documents/Invoices`, `Images/Screenshots`, or `Review/Large Files`. Paths that try to escape the selected root are rejected. Rules cannot execute scripts or address arbitrary locations elsewhere on the disk.
Rename templates can include the original name, extension, modification year, month, day, parent folder, and a sequence number. Preserve the extension unless you intentionally want an extensionless filename. Changing a suffix does not convert file contents, so renaming a JPG to PNG would only create a misleading name.
Preview several results to catch doubled extensions, missing separators, or duplicate output names. Sequence numbers are helpful for a known ordered batch but can change when the source collection changes. If stable identity matters, retain part of the original filename.
Preview rules without writing files
Scanning collects metadata. Preview evaluates the selected rules in a worker and checks proposed destinations, but it does not create folders or write files. Use the table to compare current paths with planned paths and actions. Search for important names, filter unchanged items, and inspect every conflict.
Test boundary cases. Include a filename that almost matches, a file exactly at a size limit, mixed-case extensions, old and recent modification dates, a nested path, and an occupied destination. Confirm both positive and negative examples. A rule is reliable only when it avoids files that should remain untouched.
When you edit a condition, action, priority, threshold, or nesting group, generate a new preview. Do not rely on a plan created from an older rule state. The preview summary helps with scale, while individual rows expose logic mistakes.
Choose a conflict policy before execution
Keep both is the protective default. If a destination name is already occupied, the organizer chooses an available numbered name instead of overwriting existing bytes. Skip existing leaves that operation alone. Replace existing requires explicit acknowledgement because the prior destination contents are not saved for session undo.
The filesystem can change after preview, so execution checks conflicts again. The activity log records the path actually used and any skipped, warning, or failed operation.
Run rules safely and understand undo
Approved operations run sequentially. Moves use copy, byte verification, and source removal. A failed write or verification keeps the original. If removal fails after a successful copy, both files remain and the log reports a warning. Pause or cancel stops the queue between operations.
Avoid editing the same files from another program during a run. Keep enough free space for copies and for safe moves that temporarily hold both source and destination. Rescan before running another rule set after a partial result.
Session undo can reverse supported moves, copies, and renames while the current tab retains records, destinations are unchanged, and original paths are available. Fingerprint checks protect against reversing a file another application modified. Undo does not restore replaced destination contents or guarantee recovery after the tab closes, so keep independent backups.
Save and maintain reusable rule sets
Custom rules are stored in localStorage on the current browser. Export JSON when you want a separate backup or plan to use the rules elsewhere. Imports are validated for known conditions, actions, numeric values, nesting depth, and safe paths. The export does not contain selected file contents, handles, or scan results.
Review saved rules whenever naming conventions or folder structures change. A rule that was precise last year can become too broad after a project adopts different filenames. Use an on-demand session: select the folder again, scan current metadata, inspect a new preview, and approve only what still fits.
Browser file automation should remain legible. A short list of stable, specific rules is easier to trust and maintain than a dense tree designed to cover every possible exception.