File renaming: keep identity and conflicts clear

Retain the item being edited.

Dropbox shows a file icon and the current Screens.jpg name in its rename form. Documents keeps surrounding file and folder context visible while one file name is editable. These references help the person connect the text field to a particular item rather than an anonymous naming task.

Show enough identifying context for similar files. A thumbnail, type, location or recent timestamp can help when several items have nearly identical names. Do not assume a truncated prefix uniquely identifies a document. Let the person inspect the full name without opening an unrelated detail screen and losing the edit.

Preserve the file’s stable identity underneath the visible name. A rename should not break in-app references merely because a list has been resorted. After saving, keep the renamed item discoverable, even if alphabetical sorting moves it elsewhere. A brief confirmation can identify the result without pretending another copy was created.

Pre-fill the name and make editing predictable.

Scan to PDF presents a Rename Document dialog with the current name, a clear control and explicit buttons. SCAN ACE uses a focused Rename screen with a prefilled receipt name and Done. Both reduce retyping while keeping the user responsible for the accepted value.

Choose text-selection behavior carefully. Selecting the whole editable base name can support replacement, while leaving the cursor at the end may suit adding a suffix. Either way, avoid a keyboard appearance that hides the only confirmation action. Clearing the field should not immediately rename the file to an empty string.

Define extension handling instead of leaving it accidental. If the extension is protected, show the file type and make the editable base name clear. If changing an extension is supported, distinguish that operation from real file conversion and explain a potentially misleading result before commitment.

Use action labels that match the naming task.

iLovePDF pairs its Create a new name for this file prompt with Rename and Cancel. PDF Converter similarly uses Rename File and a Rename action while the keyboard is open. The repeated verb can be useful because it makes the final button’s effect specific to the task.

If the surrounding product uses Save or Done, make the task title sufficiently clear. Avoid an action that appears to export, duplicate or finish a larger editing session when it only changes a name. Cancellation should restore the prior name and return to the selected item without applying partially entered text.

Validation should preserve the typed proposal. If the name is unsupported or unavailable, explain the specific problem near the field and keep the text available for correction. A generic failure that closes the form forces someone to reconstruct the edit and may make them unsure whether the original file survived.

Treat a name as text, not a filename guess.

Space Cleaner uses a Rename dialog with a prefilled name and OK. QR Reader presents a persistent Name label above the editable memo value, with Save in the navigation bar. These screens illustrate compact input patterns, but the product still needs a truthful validation policy behind them.

Support the characters and naming rules of the actual storage destination. Do not strip spaces, accents or non-Latin scripts merely to make implementation easier. If a provider rejects a character or length, explain its rule and preserve the proposed value. Case differences may be meaningful in one destination and conflicting in another.

Keep autocorrection and keyboard suggestions from silently altering an accepted filename. A person should be able to review the final value before saving, especially when entering an identifier rather than prose. Whitespace-only names, trailing spaces and very long names need explicit handling that remains consistent between local and remote storage.

Show a real choice when a name already exists.

Essayist’s recorded system file operation presents Replace Existing Item with Replace, Keep Both and Stop. Clarity’s file picker shows a similar Replace Existing Items decision for text.txt. These are copying or saving conflict states, useful as adjacent examples of explicit outcomes rather than evidence about those apps’ rename implementation.

In a rename conflict, name both the proposed item and the existing destination item where useful. Keep Both should explain the resulting names if it creates a suffix or another copy. Replace needs a clear consequence and appropriate authorization; accepting a new name should not imply consent to discard a different file.

Handle a conflict that appears after an initial availability check. Another device may create the name before the save completes. Preserve the original item and the proposed name, then offer a meaningful repair. Do not show success based on an optimistic local update if the storage operation has actually failed.

Validate against the real destination.

Use stable file identifiers and a destination-aware naming operation. A client-side check can improve feedback but cannot settle a conflict that occurs at commit time. Apply the storage provider’s actual constraints and return a structured result so the UI can distinguish a conflict, permission problem, unavailable location or unsupported name.

Keep the current name until the operation is confirmed, or make any optimistic state recoverable. If the app is interrupted, reconcile the item by identity rather than assuming its old path is still valid. A successful rename should update the relevant list and detail view without creating duplicate records for one file.

Define how shared links, recent items, search results and pending exports respond to a rename. Do not promise that every external link survives unless the product can verify that behavior. When a conflict needs user action, keep both the original and proposed names available and avoid retrying a potentially destructive replacement without a deliberate decision.

Test the name that comes back from storage.

Rename two similarly named files, cancel one edit and attempt a conflicting name in the same destination. Check the actual stored item and the refreshed list. Include an unchanged name, an extension-like suffix, non-Latin text, a long name and a whitespace-only proposal. Verify that validation preserves useful input.

Repeat with a remote location, denied permission, an interrupted request and another device creating the same name concurrently. Measure incorrect-item edits, lost proposals and unexpected duplicate or replacement outcomes. The number of successful text submissions is not enough if the final stored name differs from what the person reviewed.

Give the input a persistent accessible label and announce errors without erasing text or moving focus unpredictably. Keep Cancel and the confirmation action reachable above the keyboard. Let the full current and proposed names be read, even when the surrounding file list uses visual truncation for compactness.

Review the naming contract.

Use these checks on a working build, not only on the polished reference state.

• ✓Retain the file identity and current name.
• ✓Define base-name and extension behavior.
• ✓Separate rename from copy, move and conversion.
• ✓Preserve proposed text after validation failures.
• ✓Resolve destination conflicts at commit time.
• ✓Verify the actual stored name and a recoverable cancellation.

Related document-product decisions

When naming is part of an output flow, compare the sharing and export examples and make the saved artifact distinct from a renamed source.

For storage failures and unavailable destinations, review the error-state examples so the person can repair the name without losing their original item.