Generate UUIDs only after you have frozen the import rows and chosen a stable source key. Then map each generated line to that key in a working copy, test a small import, and query the destination to prove that the identifiers reached the intended records.
Build a reversible mapping before generating identifiers
The safest mapping starts with a source value that already identifies each row. It might be a legacy product key, an order reference, or a migration-only row ID. It should be present, stable, and unique within this import; a display name is usually too easy to duplicate or change.
For example, suppose a catalog migration has 137 records with legacy_sku, product_name, price, and a new empty product_uuid column. Save the untouched export separately, make a working copy, and add a source_sequence column containing a fixed sequence. Confirm that the 137 source keys are nonblank and unique before creating any new values.
The untouched export is evidence, not a disposable intermediate file. If a later lookup shows that legacy_sku A-104 received the UUID intended for A-105, you need a known starting point to locate the first shifted row. A page full of correctly formed UUIDs cannot reconstruct that relationship.
Freeze filters and sorting while the mapping is being created. If the data must be reordered, sort the entire row range and recheck the source key before adding identifiers. Sorting only the new column breaks the mapping even though every individual value still looks valid.
Generate exact batches and label their boundaries
The UUID Generator creates UUID v4 values in batches of 1 through 100. It can remove hyphens, change letters to uppercase, and copy the newline-separated result. Keep the default hyphenated lowercase form unless the receiving schema explicitly requires another representation.
For the 137-row example, generate 100 values for source sequences 1–100 and 37 for 101–137. Record the batch label, source-sequence range, source-key range, expected count, and generation date in a small control sheet. Paste a complete batch into the first empty cell of product_uuid; do not paste one value at a time while scrolling.
The tool produces text only. It does not open a CSV or spreadsheet, detect the UUID column, count source records, edit a file, or remember which output line belongs to a product. The mapping exists only because the working copy preserves row order and the batch record ties an output range to source keys.
RFC 9562 defines UUID v4 using random or pseudorandom data with fixed version and variant bits. That explains the identifier format, but it does not solve mapping or reconciliation. The same specification says applications must consider the consequences of collisions and that absolute global uniqueness cannot be promised without a shared knowledge mechanism. Keep a unique constraint or duplicate check in the destination rather than treating visual randomness as a database control.
Validate format, count, and row association separately
One check is not enough because different failures can produce the same “import completed” message. Validate the new column on three independent dimensions before sending it anywhere.
- Count: the number of nonblank UUID cells must equal the number of intended import records, excluding the header, notes, totals, and intentionally skipped rows.
- Format: every value must match the exact representation accepted by the destination. Check hyphens, case, surrounding spaces, quotes, and field length.
- Association: each
product_uuidmust remain on the same row as itssource_sequenceandlegacy_skufrom the recorded mapping. - Uniqueness: check the full proposed column for duplicates and let the destination enforce its own uniqueness rule where required.
Inspect the first and last row of every batch, plus records around the 100/101 boundary. Also sample rows with commas, non-ASCII text, empty optional fields, and long descriptions because those values can expose a separate CSV parsing shift.
Do not repair a shifted batch by filling a few visible gaps. Return to the preserved working copy, identify the affected source range, and rebuild that mapping as one controlled unit. Mark the faulty batch as abandoned so it cannot be mistaken for an alternate valid file later.
Test the destination mapping with a deliberately small import
Create a test set of three to five synthetic or approved non-sensitive records. Include one ordinary row, one empty optional field, and one field containing a comma or quotation mark. The test should exercise the same column order and import configuration as the full job.
In the destination's import screen or API mapping, explicitly bind product_uuid to the identifier field and legacy_sku to a retained reconciliation field. Do not rely only on similar column names. If the destination can validate without committing, use that preview first; if it cannot, use a disposable test environment or the documented staging process.
After the test reports success, query the records back by legacy_sku. Compare the stored UUID for the first, middle, and last test records with the mapping copy. Also inspect neighboring fields such as product name and price. A syntactically accepted UUID in the wrong column or on the wrong row is still a failed import.
If the endpoint accepts JSON, the CSV to JSON converter can turn an authorized pasted sample into an object array so you can inspect which headers become keys. It does not open or modify the source file, infer field types, or enforce the destination schema. The JSON Formatter can check JSON syntax and structure, but it cannot decide whether legacy_sku and product_uuid refer to the same product.
Reconcile the full import and retain an audit trail
Run the full import only after the small set reconciles. Preserve the exact mapping input, import configuration, timestamp, destination job ID, accepted and rejected counts, and the source-key ranges for each UUID batch.
Query a representative set back from the destination. Include the first and last record, every batch boundary, at least one rejected row, and several records chosen by source key rather than by position. Compare both the identifier and nearby business fields. If the destination returns only a success count, that is not enough evidence that row association survived.
Handle rejected rows without regenerating IDs automatically. Correct the rejected record in a new working copy and reuse its already assigned UUID when the import is a retry for the same logical object. Creating a fresh value on every attempt can turn one source record into several destination objects.
Existing destination records require a different workflow. Export their current identifiers and match them back through a reliable business key. A generator is appropriate for genuinely new objects, not for replacing identifiers already referenced by orders, logs, or related tables.
Know when this browser tool is the wrong layer
A manual generator is suitable for a small, controlled batch where a person can inspect the full mapping. It becomes error-prone when thousands of rows, concurrent edits, repeatable migrations, or transactional rollback are involved.
For a larger migration, generate identifiers inside a reviewed script or import pipeline that reads a fixed source, writes a mapping artifact, rejects duplicate source keys, validates the destination schema, and produces machine-readable results. Keep the browser tool for samples or a small one-off set, not as a substitute for an idempotent migration process.
UUIDs also should not be treated as access secrets or readable business numbers. Version 4 values are identifiers. Authorization still belongs in the application, and customer-facing references may need a separate format designed for support and communication.
Frequently asked questions
Should a 137-row sheet receive 137 or 138 UUIDs?
Generate one value for each actual import record. Do not count the header, notes, totals, or blank trailing rows; confirm the intended record count from a stable source-key column.
Can the UUID Generator edit my CSV or XLSX file?
No. It outputs text for you to copy. It does not open, inspect, edit, or save spreadsheet files, and it cannot select the correct destination column for you.
Is it safe to remove hyphens or use uppercase?
Only when the receiving schema documents that representation. The page can change the output style, but it cannot know which length, case, or validation rule your destination accepts.
Does UUID v4 eliminate the need for a unique database constraint?
No. Version 4 makes collisions unlikely when generated correctly, but the receiving application still needs controls appropriate to the cost of a duplicate, including a uniqueness check or constraint where required.
What should happen when one row is rejected and retried?
Keep the UUID already mapped to that logical source record unless the destination's documented process says otherwise. Regenerating on every retry can create duplicate objects and makes reconciliation harder.