Google Merchant Center Feed Errors: Invalid GTINs, Tabs and UTF-8

Last updated: August 2026 · By the CSVUndo team · 9 min read · Applies to Merchant Center product feed uploads · Not affiliated with or endorsed by Google Merchant Center

Google validates every submitted gtin value against the GS1 standard: it must be 8, 12, 13 or 14 digits with a correct check digit, and a value containing characters that are not numerals is flagged as an unsupported format.

Which invalid GTIN error is Merchant Center showing?

GTIN problems are reported as item-level issues — in current Merchant Center they surface under Products → Needs attention — and the exact wording tells you which fault you have:

• “Invalid GTIN in unsupported format” means the value is not shaped like any GTIN type: it contains characters that are not numerals (exactly what scientific notation produces), has a digit count other than 8, 12, 13 or 14, or fails check-digit validation. This is the classic post-Excel error, and Google’s own fix page points at the GS1 check digit calculator.
• “Invalid value [gtin]” is the same family of fault reported against the product data specification: a wrong length, bad characters or a failed checksum in the gtin attribute.
• “Incorrect GTIN” is different — the value passes format and checksum validation but is the wrong number for that product. Google notes it tends to occur when the GTIN from another product is accidentally re-used, and a barcode mangled into somebody else’s valid code lands here too. Never invent a GTIN to clear the error; submit the manufacturer’s number. Its sibling “Incorrect product identifier” fires when the gtin, mpn and brand combination doesn’t match the product.
• “Limited performance due to missing value: GTIN” is a warning rather than a rejection: the product has a manufacturer-assigned GTIN but the feed didn’t include it, and such offers may get limited visibility.

Two footnotes before you repair anything. “Restricted GTIN” means the code uses a GS1 prefix range Google won’t take — 02, 04 or 2 (restricted distribution) and 05, 98 or 99 (coupons) — and no spreadsheet repair fixes that. And severity varies: some GTIN faults block the offer while others only limit visibility, so trust the wording in your own account over any blog’s blanket “disapproved”. Whatever the length, submit digits only.

Why does the gtin column say 8.7986E+11?

Excel’s default General format displays long runs of digits — roughly 12 digits and up — in scientific notation, and when the sheet is saved back to CSV or tab-delimited text, that display string is what gets written into the file. The number itself is fine inside Excel: a GTIN is at most 14 digits, comfortably inside Excel’s 15-significant-digit precision, so nothing is rounded away while the workbook is open. The loss happens at the save, when 879860004073 leaves the sheet as the eleven characters 8.7986E+11. Merchant Center then reads those literal characters as your product’s gtin, sees an E, a dot and a plus sign, and correctly reports an unsupported format.

Recovery is honest but bounded. Expanding 8.7986E+11 yields 879860000000 — the five significant digits the display string kept, padded with zeros — and if the true barcode had non-zero digits in those trailing positions, they are simply not in the file any more. The check digit is the safety net: it is the rightmost digit of every GTIN, computed from all the others by GS1’s alternating 3-and-1 weighting, so a wrongly zero-padded expansion usually fails validation. 879860004073 checksums correctly; its padded expansion 879860000000 does not — and rows like that need a fresh export from your product database, not more guessing. The general mechanics are in the scientific notation guide.

Where did the leading zeros go — and why does length matter more than the checksum?

Opened by double-click, Excel types any digits-only cell as a number, and a number has no use for a leading zero — so a UPC that begins with 0 comes back 11 digits long. Eleven is not a valid length for any GTIN type, so the value fails Google’s format check before the checksum is even considered. That’s worth knowing because it shapes the repair: the fix is to restore the code to its standard width, not to hunt for a checksum error.

The sneaky case is the EAN-13 that begins with 0. Many North American products carry a 13-digit code that is just the 12-digit UPC with a zero in front, and the two forms share the same check digit — so a zero-stripped EAN-13 collapses into its perfectly valid UPC twin and can sail through validation without a single error. GS1 treats those as the same item, so nothing may break, but it means “no red rows” is not proof the column is intact: pad the column back to the width your catalog actually uses instead of only chasing the errors Google happens to raise. The wider story of this failure is in why leading zeros disappear from CSVs.

How do I repair the feed file before resubmitting?

Both repairs work on the raw file — comma- or tab-delimited; the separator is auto-detected — and nothing you drop on the page is uploaded anywhere. The site’s Content-Security-Policy sets connect-src 'none', so the browser blocks every data connection the page could open — including one back to us. Check it yourself in 30 seconds.

1. Drop the feed on the scientific notation fixer and click Show me what Excel broke. It counts the damaged cells and expands them for you, across the whole file — but never on shape alone: a cell has to match what Excel’s own General format writes before it is touched, so a genuine part number like 2E5 is left exactly as it is.
2. Download the repaired copy: every expanded value is written back as full digits, with the delimiter and column layout untouched.
3. Run that file through the leading-zeros fixer. Padding is the one repair you pick columns for, because only you know how wide a code is meant to be: tick gtin and set the standard width — 12 for UPC, 13 for EAN. A column whose header names a standard-width code (ZIP 5, UPC 12, EAN/GTIN 13) arrives pre-ticked at that width, provided no value in it still starts with a zero — one that does proves Excel never stripped the column; every other digit-only column is listed unticked with the width box pre-filled from its longest value, so read that number before you tick it.
4. Resubmit the feed. In current Merchant Center you can also fix items individually or download the affected-products .csv from the issue page, and Google says changes can take 24–72 hours to reflect on the Needs attention page — so give a fix time to register before repairing the same rows twice.

Does Merchant Center accept CSV, or does the feed have to be tab-delimited?

Google’s file-format documentation lists .txt, .xml and .tsv as the supported product file types — plus compressed .gz, .zip and .bz2 archives containing a .txt or .xml file, up to Google’s 4 GB feed limit. .csv is not on that list, and neither are native Excel workbooks. The picture is muddier than “CSV is rejected”, though: Google’s own fix flows hand you affected-product downloads as .csv. The dependable route is tab-delimited — Google’s documented Excel export is File → Save as → Text (tab delimited)(*.txt), and the Google Sheets equivalent is File → Download → Tab-Separated Values (.tsv).

A tab-delimited feed has structural rules of its own: the header must be the first line, one product per line, no trailing tabs at line ends, and no tabs or line breaks inside attribute values; where a comma inside a value is not separating repeated values, the value must be surrounded by quotes. Attribute names are submitted in English with underscores — image_link, not “Image Link”. If what you actually have is a comma-separated file, resist the find-and-replace instinct: swapping commas for tabs in a text editor also rewrites the commas inside product titles. The CSV ⇆ TSV converter re-serializes the file properly, keeping quoted fields intact either direction — the format differences are covered in the TSV to CSV guide.

What does “Invalid UTF-8 encoding” actually mean?

It means the bytes in the feed are not valid in the encoding Merchant Center is reading it as — Google’s help page sums it up as “Something is wrong with your encoding for text.” Merchant Center supports UTF-8, UTF-16, Latin-1 and ASCII, offers an Autodetect option, and reports mismatches at two levels. Item-level hits are typically shown with the affected attribute in brackets — “Invalid UTF-8 encoding [description]” is the form agencies report — while a mismatch across the whole file produces the data-source error “An invalid encoding was specified for the product data source”. For that one, Google’s fix in current Merchant Center is Settings → Data sources → your product source → Data source setup → Show advanced settings, the pencil next to Encoding, pick the encoding the file is really in, save, and resubmit the feed.

Diagnose before you change settings. The encoding checker reads the file’s actual bytes and tells you what it truly is — which regularly contradicts what the export dialog claimed — so you know whether to fix the file or the data-source setting. And note the counter-intuitive case: mojibake such as é or ’ baked into product titles is often perfectly valid UTF-8, so no encoding error fires at all — the feed processes cleanly and shoppers see the garbage in your listings. (Google raises a separate issue, “Invalid characters [title]”, only when a broken round-trip leaves private-use characters behind.) Baked-in mojibake needs the broken characters fixer, not a different encoding setting.

How do I stop Excel breaking the next feed?

Keep Excel from ever parsing the gtin column as a number. Microsoft’s documented workarounds are formatting the cells as Text — which only protects entries made after the formatting — or prefixing each code with an apostrophe. Better: import the file in a way that declares the barcode column as Text before Excel parses it, or keep the feed master in Google Sheets and download it as Tab-Separated Values (.tsv), which sidesteps the notation and codepage problems in one move. Above all, keep an untouched copy of every export — a repair can only restore what the file still holds.

Frequently asked questions