Shopify Product CSV Validator

This independent Shopify product CSV validator prepares local candidate files for a later product import. It is not an official Shopify product, a certified integration or a shop-management service. Start by choosing whether you intend to create new products or update existing ones. Then choose the actual overwrite option you plan to use. The tool does not infer your purpose from a column name or assume that every matching handle should be overwritten. Those choices change the meaning of the review.

Only the product CSV workflow is covered. Orders, customer migration, multiple-location inventory management and complete store migration require their own processes. You do not provide a shop key, and the tool never uploads the prepared file to a store. Product descriptions are shown as text, so supplied HTML is not executed in the preview. Image addresses are inspected as strings and are never fetched by this workbench.

Import CSV, TSV, pasted cells, an explicitly verified XLSX region or the current table from a previous tool. Confirm each input interpretation before mapping fields. A selected workbook range is a value source, not a promise to preserve macros, formulas or formatting. Product identifiers, SKUs and barcode text remain strings. If your spreadsheet has already rounded a barcode or removed leading zeros, recover the original source before preparing a machine import file.

The page displays the rule version, official source addresses and last verification date. This release uses shopify-product-csv-2026-09-29.1. Current field documentation and the official sample are not completely synchronized: for example, the retrieved sample still contains the older singular Barcode heading while the current field description uses Barcodes. The implementation keeps an explicit alias table and flags unsupported or store-specific fields rather than treating every similar-looking header as equivalent.

Automatic suggestions are restricted to exact current headers and recorded legacy aliases. You can manually correct a known mapping, but every source column must still have a unique target header. Unknown columns remain present and are marked unverified. They are not silently deleted so the remaining file can be called valid. Store metafield definitions, product taxonomy, market-specific semantics and custom service configuration need additional verification beyond this local structural check.

The product review groups rows by the mapped product handle when supplied. A group can contain a main product row, variant rows and additional image rows. These roles matter: an attached row may legitimately omit the product title and description while remaining part of a complete product. The summary counts product groups, variant candidates and image-only rows separately. It does not advertise the total row count as a product count.

Each group needs an identifiable product title in its primary row. Variant combinations must be distinct within that group, and option names and values must form a consistent structure. The tool checks mapped dependencies instead of applying a generic required-title rule to every line. A repeated handle is therefore not automatically a duplicate record, whereas a repeated option combination can block a product group. Rows that cannot be assigned a supported role are reported for correction.

Duplicate SKUs are a configurable business risk rather than a universal platform error. Select the stricter local policy only if your own workflow requires it. Product identity is not determined by SKU alone, and product names are not fuzzily merged. The default preparation does not invent a price, an active status or other missing behavioral values. Where a platform default could apply, the review names that potential behavior for you to inspect.

For every mapped field, choose a submission intent: set from the file, omit the entire column, or explicitly submit blank. Setting from the file includes its blank cells. A blank cell in a submitted column is not an instruction to leave a value unchanged. Omitting a column means it is absent from that particular candidate file. The effect still depends on the field, its dependencies, the row role and the actual import settings, so the tool does not apply one universal blank-clears-everything rule.

For example, review a synthetic baseline in which product A has Vendor Acme. An update that omits Vendor and one that submits an empty Vendor cell produce different candidate effects. A required or default-bearing field can have different semantics from Vendor. The packed-dimension fields are another deliberately separate case: their blank behavior is reviewed with the row role and shipping setting, rather than being treated as ordinary product description text. Read the effect and certainty columns together.

If A should clear Description while B should leave Description unsubmitted, override the field intent per product. The preparer splits complete product groups according to compatible submitted-column sets. A goes into a candidate file containing the description column; B goes into one that omits it. Both products retain their attached rows. The tool does not represent these incompatible intentions with two indistinguishable blank cells in one shared column, and it does not silently backfill values from an uncertain baseline.

You may supply an existing product export as a baseline. Record its export date, source and coverage and explicitly confirm those details. The local review policy treats missing metadata, a future date or a snapshot older than thirty days as unreliable context. That freshness threshold is a product review policy, not a Shopify import requirement. Even a recent baseline cannot prove the live store state or that no one edited the store after the export.

With suitable evidence, the effect table shows the baseline value, incoming file value, submitted value, field intention and conditional expected effect. Without reliable evidence, effects remain potential-only. The page does not claim a definite count of live products that will change. Variant option edits and omitted variant-related columns receive additional risk reporting, because local row matching cannot fully simulate the platform operations or downstream systems that depend on variant identities.

The baseline is not used to guess missing values or automatically repair product data. When a field cannot safely express your intention, adjust the input or mapping and run again. You can undo settings or product overrides, but any new input or rule changes makes the old result stale. Fresh review is required before downloading the updated candidate. Preserve a copy of the original files so the difference between source evidence and prepared output stays visible.

The result separates blocking issues, warnings and unverified items. Numeric syntax, supported boolean values, option dependencies, row ownership and duplicate combinations are checked within the implemented scope. Unknown custom fields, image access, taxonomy and store-specific configuration are not counted as passed checks. The tool does not invent a data-safety percentage or claim that an untested rule succeeded. Source references help you locate the record responsible for each issue.

An image URL can have acceptable syntax and still fail when a platform later tries to retrieve it. Accessibility, credentials, image bytes and dimensions are not verified here because the converter does not visit user-supplied addresses. A video or three-dimensional model cannot be validated merely by placing its URL in an image column. Use the appropriate official media workflow and a separately authorized test destination for those tasks.

No value-changing repair happens silently. Field mapping changes, explicit clearing and per-product omissions are visible in the candidate preview and effect review. If an erroneous product is excluded, its entire group is excluded, including attached variant and image rows. The download does not remove one bad variant and then present the rest as the complete original product. A global mapping or required-column problem blocks every candidate until corrected.

The candidate writer uses English machine headers, commas, UTF-8 and LF line endings regardless of the interface language. It preserves raw field text. General spreadsheet formula-prefix protection is not automatically inserted into a product import file, because a protective apostrophe could change a SKU or description. Instead, formula-like values are flagged and the machine export asks you to review that risk explicitly. Use a separate protected report when you need spreadsheet-oriented review material.

Before downloading, every complete candidate partition is checked again against the local rules and parsed again with the CSV reader. The review reports how many products, rows and files are included and how many erroneous groups were excluded. Multiple compatible-column partitions are delivered in a ZIP with neutral numbered filenames. Download effect explanations and error-product reports separately if you need them; the candidate itself contains the intended product fields.

This release has not been imported into an authorized isolated Shopify test store, so the result is a structural preparation check, not a guarantee of import success. There is no automatic production import. Processing is local and cancellable, with size, output-file and time limits. The website still loads static resources, while source product content stays out of third-party validation APIs. Refreshing clears the session, so save reviewed outputs deliberately.