Block structural errors first
Duplicate outputs and common invalid names become blocking errors before rename execution, reducing surprises after a batch is downloaded.
What does FileNest actually check before a batch runs?
This evidence does not use 'safe' as a slogan. It separates the checkable safeguards in the current production renamer and image batch flow: what can be reviewed first, what blocks execution, what is only advisory, whether source files are overwritten, and how output-name collisions are handled.
Pinned production source
8 checkable production behaviors
Compiled from the batch-renaming, image-conversion and output-naming source pinned to the production commit. It records safeguards that can be checked in the current implementation without stretching UI protections into a zero-risk guarantee.
Pinned production commit: c35d0c7a; 3 production source files referenced.Old-name → new-name preview before execution
The rename workspace computes and displays the original filename, proposed filename, warnings and errors for each file so the batch can be reviewed before ZIP creation.
Source: components/RenamerTool.tsx
Duplicate output names block the batch
Proposed output names are checked case-insensitively for duplicates. A collision becomes a blocking error instead of waiting until ZIP creation to reveal the conflict.
Source: components/RenamerTool.tsx
Common unsafe filename conditions are blocking
Current checks cover empty names, slash/backslash, control characters, common reserved symbols, trailing spaces or periods, Windows reserved names, and output names beyond the current 180-character limit.
Source: components/RenamerTool.tsx
Extension loss is warned, not forcibly blocked
If a source file has an extension but the proposed output does not, the workspace warns the user. It remains advisory because removing or changing an extension can be intentional.
Source: components/RenamerTool.tsx
Blocking errors disable execution
When the rename batch contains blocking errors, the action that creates the downloadable ZIP remains disabled until the naming conflict or invalid output is resolved.
Source: components/RenamerTool.tsx
Renaming creates a new ZIP without overwriting originals
Execution uses the existing browser File objects and writes them into a new ZIP under the proposed names. FileNest does not directly overwrite or delete the source files on the user's device.
Source: components/RenamerTool.tsx
Batch images expose per-file source thumbnails
Image batches create browser Object URLs for the added source files and show clickable thumbnails in multi-image batches so each source image can be inspected before processing.
Source: components/ImageConverterTool.tsx
Image output name collisions get deterministic suffixes
Image outputs use a case-insensitive set of names already used in the batch. Collisions are resolved deterministically as name (2), name (3), and so on to avoid same-name results in the ZIP.
Source: components/ImageConverterTool.tsx · lib/file-names.ts
Why preview first
Why this matters more than a one-click batch promise
Human intent still needs review
Extension changes and sequence choices may be intentional, so the preview does not pretend software can decide every project-specific naming meaning.
Keep sources separate from outputs
Renamed results go into a new ZIP instead of directly rewriting or deleting source files on the user's device.
Scope limits
What this evidence does not guarantee
- This evidence currently covers preview, naming and original-file protections in batch renaming and image batches; it does not claim every FileNest tool uses the identical safety flow.
- Filename validation catches structural collisions and common invalid names, but it cannot decide whether project-specific naming semantics are correct, such as whether a sequence matches the user's real intent.
- Extension loss is advisory rather than a hard block because a user may intentionally change an extension; human review before execution still matters.
- Image thumbnails preview the source files added to the batch. They are not a pixel-level pre-execution guarantee of every conversion, compression or enhancement result.
- This report does not test browser/device matrices, performance, peak memory or batches beyond current tool limits. Browser downloads and ZIP creation can still be constrained by device resources.
- This is a snapshot pinned to a production commit. If a current tool page conflicts with older evidence, prefer the current tool page and update this report.