Importing a CSV

If your collection already lives in a spreadsheet or in another collection tracker, you can bring it in as a CSV. It works the same way importing cards in bulk does — you preview exactly what will be written before anything is — with one extra step at the front: choosing the file. There are three screens: the file, the form (which counts, where they go, what condition), and the preview.

There are two ways in:

• Collections → Import starts from the file and lets you send it to a collection you already have, or to one it creates for you.
• Add cards → Bulk add → From a file, inside a collection, imports into that collection.

Importing is only available in collections you own, and it needs a connection and the card database, which installs in the background the first time you use Pitchstack.

Choosing the file

Drop a .csv (or .txt) file on the box, or press Choose file. Files up to 25 MB and 50,000 rows are read, with up to 256 columns on a row; anything larger is refused with a note rather than left to freeze the page. A file refused for its columns is usually not a spreadsheet at all — an export that went wrong, or the wrong file entirely.

If you already had a file loaded and the one you chose to replace it is refused, nothing you had changes: the file and the counts you picked stay exactly as they were, and the message says which file is still loaded. The same goes for a file your device cannot hand over at all. Choosing a replacement should never be able to cost you the work you have already done on the one you have.

Choosing a file takes you straight to the form — there is nothing left to answer on this screen — and what we read out of it travels with it. Once it is read you get a single line describing what is in it — something like 17,159 rows · 108 sets · owned counts on 3 · wanted counts on 0. That last part is worth a glance: it is how you spot a file where the column you meant to fill in is empty.

If we cannot recognise a file, we say which of the two things it is missing: a column naming each card, or a column of counts. Both have to be there.

Dropping a Pitchstack JSON snapshot here is fine too — that is a different thing (it restores a whole collection under its own name), so we hand it straight to the restore flow with your file already chosen.

Which counts to import

A tracker's export usually has several count columns — what you have, what you want, what you have spare. Import is where you say which of them this import reads:

• Owned — the cards you have.
• Wanted — the cards you are looking for.
• Extras for trade — the spare copies you would let go.

Pick as many as you like: the chosen columns are added together on each row. A catalogue that records a card as two owned and one spare for trade is describing three cards, and choosing both brings in all three — a column your file left blank on a row simply contributes nothing.

Only the columns your file actually has are offered, and a file with exactly one (a Pitchstack export, which just has a quantity) shows it as a fact rather than a control. Where there are several, Owned starts out chosen on its own, and adding to it is yours to do — worth a glance either way, since the line above tells you how many rows each column actually has. Clearing the field entirely leaves nothing to import, and Review says so.

Rows that are blank or zero in every chosen column are dropped straight away. That is the big reduction — a whole-catalogue export with three counts in it becomes three rows.

Where it goes

Destination is any collection you own, or New collection…, which asks for a name and a type and creates it as part of the import. The type that suits what you picked is listed first — Owned suggests a binder, Wanted a wantlist, Extras a tradelist, and anything summed with Owned suggests a binder — but you can send it anywhere.

The collection is created when you press Review, and the importer stays put while that happens — Cancel, Escape and clicking away are all held for the moment it takes, so you cannot end up with a collection you abandoned and a file you have to pick again. If the import then fails, the summary tells you the new collection exists, so you never find one you do not remember making.

Condition is part of how cards are matched — importing at Near Mint tops up your Near Mint copies.

If the file has no condition column, this one condition covers the whole import. If it has one and every row fills it in, each row uses its own and the field disappears. In between — a condition column with some cells left blank — the field stays, renamed Condition for rows that don’t say, because a blank cell does not import as no condition: those cards come in at whatever this field shows, and merge with any row that names it outright. The preview counts them.

What gets imported

Review goes straight to the preview. Every row we could match to one printing is imported — there is no list to tick — and how sure we are is part of the match rather than a question for you:

• Exact — everything the file named agrees with the printing. Imported.
• Probable — the card and finish agree, but a treatment could not be honoured. Extended Art in particular is often just the plain foil printing on our side. That holds however we found the printing: a row matched by its id and asking for an art that id does not spell is probable too, rather than exact. Imported.
• Matched more than one printing — we found several and will not guess. Left out; name the printing in the file (a complete code like MST095-RF, or a Foiling and Edition column) to bring it in.
• No match — nothing to import; the row says why (an unknown set printing id, no printing in that foiling, a set number that belongs to a different card, or a row that names two different cards at once). Left out.

The preview counts both of the left-out kinds in its own account of what it is not writing, and Copy unmatched rows puts every one of them on your clipboard as a table, with the line numbers from your file and the reason for each, so you can fix them at the source.

Review stays out of reach — saying why — while the file, the counts you have chosen and the destination leave nothing that could be imported at all.

If the card database finishes updating while you are on the preview, Import waits and the totals are worked out again against the new one — the figures on screen were worked out against the old database, and a row could land on a different printing.

Recognised columns

Column names are matched loosely — capitals, spaces, and punctuation do not matter — and only the ones you have are used. Anything we do not recognise is ignored.

Naming the card. At least one of these has to be there.

Your set code is checked against your set number. If a row gives a complete printing code like MST095 and a Set code naming a different set, the row is left out and named with its line and both cells, rather than importing into one of the two sets and being listed under the other. A set code that only spells the same set differently — CRU beside U-CRU178, or the whole code repeated — is not a disagreement, and neither is a Set code cell that names no set code at all. And where a row's only identifier is a Product ID or a Printing ID, your set code is checked against the set that id actually lands in: two reprints of one card are two different products, so a Set code naming the other one is shown as No match rather than importing the reprint you did not ask for. A code that spells two sets — the LGS360-FUN001 family — agrees with either half.

Your pitch is checked too. A Pitch beside a set number has to be the pitch of the card that number belongs to. A number that has slipped a row up a spreadsheet lands on a real printing of a different card, and where your file said red and that card is blue, the row is shown as No match rather than imported as the card the number happens to name. A blank pitch says nothing and agrees with anything, and a card with no pitch at all — equipment, a weapon — agrees with none and disagrees with a colour.

Both of the card columns are checked, not just one. If your file gives a Card ID and a Card name and they name two different cards, the row is shown as No match rather than matched to whichever of them we looked at first — a name column that has slipped a row, or an id left behind from an older export, is exactly the sort of thing that would otherwise import the wrong card without a word. The two faces of a double-faced card are not a disagreement: an id for the whole card beside either face's name is one card written twice, and matches.

Counts. At least one of these has to be there.

Narrowing the printing. These pick between printings of the same card.

A one-word column name. Product, Printing and Identifier are read as the id columns above only where the value under them actually is an id — row by row, not column by column. A Product column of card names — which plenty of trackers write — is read as card names instead, and the file is looked up through its set numbers, which is what you wanted. Keeping the names matters: they are what catches a set number that has slipped a row or lost a digit and landed on a real printing of some other card. Identifier does the same when it holds names rather than slugs. A column that is ids on some rows and names on others is read as both, each row as what it holds, so one row can never change how another is read. And if your file has both one-word columns, neither of them owns the name: whichever cell on a row actually holds a name is the one read as one, so Product full of somebody else's codes beside an Identifier of card names keeps the names — the column that comes first does not get to speak for the row. Where both cells on a row hold a name, the same name written two ways is one name, and two different names are a row naming two cards, which is No match rather than us picking the one we saw first. A value we can make neither an id nor a name of — a row number, an internal id — is ignored. Either way the column is listed once under What was left out saying which way its rows were read. Printing is only ever ids; a printing name describes the finish and set as well as the card, so it is not a name we can check anything against. Case is part of what tells them apart, because it is all there is to go on for a one-word value: our product ids are written in capitals (1HB001, ES_ROS156-RF) and our card ids in lowercase (arousing-wave), while a card name is written neither way — so a Product value in lowercase, or an Identifier value in Capitalised Words, is read as a name rather than an id. The unmistakable spellings — Product ID, Printing ID, Card ID, Slug — are always read as ids, whatever is under them. That also means they are believed: where a one-word column's id is set aside when it disagrees with the rest of the row, an id under one of these is a statement your file has made, so a row where it names a different card from the other id, the set number or the card name beside it — or a different printing from the language, finish or edition beside it, since a product is a card in one of each — is shown as No match — "The ids, set number, set code, card name, pitch, finish, language and edition on this row do not all name one printing." — rather than us picking one of them for you. And a file that has a Card name column of its own always keeps it: nothing is re-read into a column you already filled. The same believing runs the other way: where a card name or identifier read out of a one-word column disagrees with the one your file spelled out, the spelled-out one wins and What was left out says so once for the file — but two spelled-out columns that disagree are a row naming two cards, and that is No match.

A Product or Printing column of somebody else's ids. Another tracker's own product and printing codes are written the same way ours are — capitals, digits, hyphens — so a column full of them is read as an id column and none of them names anything here. That is not the end of the row: when the file also gives a Set number, the row is looked up by that instead, and the file imports exactly as it would have without the column. What was left out says so once for the whole file rather than once per row, because the cause is the column, and it says it separately for each column that was read that way. A row whose only identifier is an id we do not know has nothing else to try, so that one is left out. And some of somebody else's codes do not simply miss — a stale or shifted one lands on a real product or printing of ours, for a card your row never mentions. So an id that resolves is still checked against everything else the row names — the other id, the set number, the set code, the card name, the pitch, and the language, finish and edition your file filled in — and a Product or Printing column whose id names a different card, or the same card in a finish, language or edition your row did not ask for, is set aside the same way a code we have never seen is: the row is looked up by what it actually names, and the column is counted once for the file. Where a file carries both one-word columns and the two ids resolve to different cards, neither of them is set aside for the other: they are two readings of the same row and nothing ranks one above the other, so the row is shown as No match — "The ids, set number, set code, card name, pitch, finish, language and edition on this row do not all name one printing." — rather than importing whichever column we happened to read second. Anything else on the row that can tell them apart still decides it: where the row's set number, card name, pitch or a stated finish, language or edition agrees with one of the two, that one matches and the other is set aside and counted for its column, and where it agrees with neither, both are set aside and the row is looked up by what is left.

Two columns for the same thing. Some files carry both a Quantity and a Qty, or a Note and a Comment — two spellings we recognise for one field. Only the first one is read; the second is ignored whole, which matters when the first is the blank or stale one. It is listed under What was left out, naming both columns and which of them we read, so you can move the values across or drop the column you do not want before importing.

A value we cannot read. A blank cell in any of these columns just means the file did not say, and the import carries on without it. A cell that does say something we cannot place — a condition of Moderately Played, a finish we have no printing of, a language we do not stock — is different, and it is listed under What was left out with its line number and the text we could not read.

A cell that is simply enormous — thousands of characters where a set number, a count or a date belongs — is treated the same way: it is listed with its line and the start of the text, and it is not read at all. Reading the first part of one would be worse than ignoring it, because the part that made it wrong is often the part that would be cut off, and a Quantity of 1 followed by a thousand spaces and an x would quietly import one copy. A note is the exception, since a note is only ever kept up to 256 characters anyway: an over-long one is shortened, and the shortening is named as usual.

Foiling, Edition, Language and Condition all decide which card you get, so a row with one of those unreadable is left out rather than imported as the plain, Near Mint, English printing it never asked for. Treatment and Pitch only help us rank, so a row still imports without them.

Extras that ride along. These are written on cards new to the collection.

A note, a price or a date we cannot read does not cost you the card: the row still imports, without that one value, and the cell is listed under What was left out with its line number. Nothing your file says is dropped without being named there.

The same holds for a value that comes across but not whole. A note longer than 256 characters imports shortened to the first 256, and a count with a fraction in it (2.7) imports as the whole number below it — both are listed under What was left out with the line, so a note that lost its tail is never a surprise you find later. Counts read their separators exactly as prices do, so one file is never read two ways.

The preview

The preview is the bulk importer's, and it says the same things: how many copies, split between cards new to the collection and top-ups of cards you already have, and what it is leaving out.

If any of your rows left the condition blank, the preview says how many and what they are coming in as.

Two lines are specific to a file import, and they are different facts. Notes, prices, trade counts and purchase dates can only be written on a new card — topping up a card you already own has nowhere to put them, including a card already at the count you asked for — so the preview says how many of your rows will lose theirs. And where two rows turn out to be the same card in the same condition, they become one card here as well: the preview says how many rows merged, and their copies all take the earlier row's note, price, trade count and date. That counts a row whose cells were blank as much as one that disagreed — its copies still arrive carrying values it never named, which is the half you cannot see coming from the file. Everything else about those rows still imports.

There is a third, rarer one, and it only appears after an import that did not finish reporting back. Those cards are sent again exactly as they were sent the first time — the same copies, note, price, trade count and date — because that is the only repeat we can be sure adds them once rather than twice. If your file has since changed its mind about one of them, the preview says so: that card keeps what the earlier import sent, and you can edit it afterwards.

Things to know

• Duplicate rows are folded together rather than added up, when the file is a catalogue: the same card listed twice, or once per face of a double-faced card, is one card. A Pitchstack export is the other way round, because its rows really are separate items.
• Two rows are only folded together when everything they say agrees. Sharing a set number is not enough on its own: if a collector number has slipped a row out of line, so that two different cards sit on one number, we keep them apart and check each against the card that number really belongs to. The one that does not match is shown as unmatched — "That set number belongs to a different card." — with its own copies, instead of quietly importing them as the card above it. Sharing a product id is not enough either, and neither is anything else a row happens to be grouped by: two rows on one product id that name two different printings, or one set number written twice in two finishes, stay apart and are each checked on their own, so the second row's copies can never arrive as the first row's card. A row that simply leaves a column blank is not disagreeing with anything, and still folds.
• Two rows count as the same card even when they spell it differently. omn109 and OMN109 are one printing, and so are JA_OMN109 and JP_OMN109 — both are ways of writing the Japanese print. The same goes for an identifier that writes the pitch as a word (inner-chi-blue) where we write the letter (inner-chi-b). They become one row, so a file that mixes spellings does not import the card twice.
• If your own export holds the same card twice in the same condition — two lots you split apart, each with its own note, price and date — the copies are added together and the first lot's note, price and date stand for all of them. We cannot keep the two apart on the way in, so rather than let it happen quietly, every lot this affects is listed under What was left out with both line numbers and exactly which values moved, in whichever direction they moved: the ones the later lot named that did not make it, and the ones it left blank that its copies now take from the first lot. The second matters most for money — three copies bought at $12.50 followed by two the file priced at nothing become five at $12.50.
• Top up to this many (the default) adds only what is missing, so running the same file twice changes nothing the second time. Add this many more always adds on top.
• Going back never loses your answers — the file, the count columns, the destination and the condition are all still there.
• Free plans cap how many cards one import can write and how many a collection can hold. The preview says so and holds Import; see limits.