TLDR: To print Moxfield decklist proxies without rebuilding the deck by hand, preserve the original list, make a separate print copy, reduce it to clean quantity-and-name lines, remove anything you do not intend to print, and import that working copy. Then verify card counts and selected versions separately before approving the project.
The import itself is the easy part. Most costly or annoying errors happen because the source list includes a maybeboard, an old sideboard, unwanted basic lands, annotations, or versions that were never deliberately selected. Treat the deck as three files: the untouched source, the cleaned import list, and the final approved record.
How to print Moxfield decklist proxies in seven steps
- Save or copy the current Moxfield list without changing it. This is your source record.
- Create a separate working file for the cards you actually want printed.
- Use one card per line, with the quantity first and the card name second.
- Remove comments, prices, ownership notes, spreadsheet columns, and unintended maybeboard entries.
- Separate the main deck, commander, sideboard, and extras so each group can be counted deliberately.
- Import the cleaned list into PrintMTG’s decklist workflow, then review matches and choose the intended card versions. PrintMTG states that its workflow supports Moxfield lists, fuzzy name matching, sideboards, tokens, and version changes after import.
- Proof the imported project against the source list before moving to checkout. Check structure first, then inspect versions and unusual card layouts.
Do not delete a questionable entry merely to make the importer accept the list. Put it into a short exception list instead. That gives you a controlled place to resolve unfamiliar punctuation, split names, special layouts, and missing matches without losing track of a card.
Preserve the original before cleaning anything
Your Moxfield deck is the source of truth, but it should not also be the file you aggressively edit for printing. Save an untouched copy or export first. The exact export controls may change, so use whichever current Moxfield option gives you a complete readable list rather than relying on a specific button sequence.
Next, create a working print list. This file answers a narrower question: which physical cards should be in this batch? It can differ from the deck page because you may already own some cards, exclude inexpensive basics, print several sideboard options, or include extra tokens.
Finally, retain the approved list after import. A useful naming pattern is deck-name, project stage, and date, such as talion-control-clean-2026-04 and talion-control-approved-2026-04. The date matters when the deck changes later and you need to determine which version was actually printed.
Clean the list before importing it
The safest working format is intentionally boring: one entry per line, quantity first, then the exact card name. PrintMTG’s published guidance supports quantity-first lines and optional section headings beginning with two slashes. It also advises removing inline notes that may interfere with matching. Review PrintMTG’s current decklist formatting guidance before importing if your copied list contains extra fields.
A cleaned Commander list might begin like this:
- // Commander
- 1 Talion, the Kindly Lord
- // Main Deck
- 1 Arcane Signet
- 1 Command Tower
- 8 Island
- 7 Swamp
- // Optional Test Cards
- 1 Consider
- 1 Spell Pierce
Section headings are organizational labels, not quantities. Keep them simple. Remove prices, collection statuses, category tags, comments, foil indicators, acquisition notes, and unrelated spreadsheet data unless the current importer explicitly asks for those fields.
If your source includes set codes or collector numbers, keep a second version-controlled record before stripping them out. A simple name-only list is useful for matching, while the identifier record preserves your art and printing decisions. Do not assume every importer interprets every identifier syntax the same way.
Make maybeboard cards, sideboards, and extras deliberate
A maybeboard is useful while brewing but dangerous in an order file because it often represents possibilities rather than decisions. Exclude it by default. If you genuinely want those cards as a testing package, move them into a clearly named section and count them as a separate batch.
Use the same rule for sideboards, tokens, emblems, copy tokens, helper cards, and alternate commanders. They should be present because you made a project decision, not because they happened to appear in copied text. PrintMTG says sideboards and tokens can be included in its workflow, but that capability does not decide which extras your deck needs.
| Component | Default action | Proofing question |
|---|---|---|
| Main deck | Include | Does its count match the source deck? |
| Commander or companion | Include intentionally | Is it already counted elsewhere? |
| Sideboard | Include for formats or testing plans that need it | Is the entire current sideboard present? |
| Maybeboard | Exclude | Are these real test cards or only ideas? |
| Basic lands | Decide per project | Do you need matching basics, or will you supply them? |
| Tokens and helpers | Track separately | Are the required types and useful quantities included? |
For a multi-deck order, repeat this separation inside each deck rather than creating one unlabelled pile of extras. If three decks need the same token, record whether you want one shared copy or one copy per deck.
Review card versions after the import
A successful name match confirms that the importer found a card; it does not confirm your preferred set, art, frame, language, or treatment. PrintMTG states that users can select print versions and change versions after importing a list. Use that review stage rather than stuffing every visual preference into a fragile text line.
Version checking is easiest when divided into two passes. First, look for functional errors: incorrect names, doubled quantities, missing cards, or an unintended similarly named card. Second, review visual choices: set, artwork, frame, border treatment, and consistency across cycles or basic lands.
Spend extra attention on cards whose presentation is not a conventional single face. MDFCs, transform cards, meld components, split cards, Adventures, Battles, and other unusual layouts should be opened in the available preview individually. Confirm that the intended faces or components are represented correctly; do not infer this from the front-facing thumbnail alone.
Commander proofing: count the deck separately from extras
For a Commander project, the playable deck count and the order count are different numbers. Wizards describes a Commander deck as exactly 100 cards including its commander, with the usual singleton exception for basic lands. Wizards’ introduction to Commander provides the official deck-construction overview. Tokens, emblems, helper cards, and spare test options do not belong in that 100-card check.
- Confirm that the commander appears exactly once in the playable-deck count.
- Check whether a background, partner, Doctor’s companion, or other command-zone component changes how your particular list is organized.
- Count the playable deck independently of tokens and helper cards.
- Decide whether basic lands are intentionally included, excluded, or included only for visual consistency.
- Compare the imported playable count with the preserved Moxfield source.
- Then calculate the complete order count by adding extras and test cards.
Suppose your source has a 100-card Commander deck, eight tokens, and five maybeboard cards. If you exclude the maybeboard but include all tokens, the project should contain 108 printed items. That does not make it a 108-card Commander deck; it is a 100-card deck plus eight separately tracked accessories.
Proof the project in two passes
Pass one: structural proofing
- Total the main deck, commander, sideboard, and extras independently.
- Look for doubled quantities caused by combining two exports.
- Confirm that no maybeboard heading or entry slipped into the order.
- Check that intentional basic lands are present in the correct quantities.
- Search for unmatched or substituted names.
- Make sure no spreadsheet columns were interpreted as card text.
Pass two: visual and version proofing
- Review the selected printing for every card where the art or frame matters.
- Check text readability in the available preview, especially on visually dark or text-heavy versions.
- Inspect double-faced and unusual layouts one by one.
- Confirm that cycles, matching basics, or repeated cards use consistent versions where intended.
- Record deliberate exceptions so they are not “corrected” during a later reorder.
For a large gauntlet or group project, proof one deck at a time. The batch may be cheaper or easier to manage as one order, but the error-checking unit should remain the individual deck. The same principle applies when deciding how many decks or test cards belong in one batch.
Archive a reproducible deck version
Once the preview is approved, save enough information to reconstruct the project without guessing. This is especially important for a deck-testing gauntlet, where small revision batches should match the earlier organization rather than becoming disconnected piles of cards.
- The untouched Moxfield source or export
- The cleaned text used for import
- The final approved card list
- Set codes or collector numbers for version-sensitive cards
- A separate list of tokens, helpers, and sideboard cards
- The deck name and approval date
- A short change log for later additions and removals
For frequent revisions, retain one master list and create a small delta list containing only cards entering and leaving the physical build. The project-control approach in this competitive deck-testing workflow is useful when several decks share staples or receive repeated updates.
Troubleshooting common import problems
| Problem | Likely check | Practical fix |
|---|---|---|
| A card does not match | Punctuation, inline notes, or extra columns | Reduce the line to quantity plus exact card name and retry. |
| The quantity is doubled | Two list sections or exports were combined | Search the working file for the card and total its entries. |
| Unwanted cards appear | Maybeboard or archived sideboard entries remained | Return to the working list and remove or relabel those sections. |
| The wrong art appears | The name matched but no version was selected | Choose the intended version during review and record its identifier. |
| The total is too high | Basics, extras, or duplicated commander entries were included | Reconcile each section independently instead of editing the total blindly. |
| The total is too low | A heading, special name, or malformed line failed to import | Compare the unmatched list with the source one line at a time. |
FAQ
Can I import a Moxfield decklist directly?
PrintMTG states that its decklist workflow supports Moxfield lists. Even so, use a cleaned working copy so you control whether maybeboard cards, basics, sideboards, and extras are included.
What should each card line look like?
Use the quantity followed by the card name, such as “1 Sol Ring” or “12 Island.” Keep one card entry per line and remove comments or unrelated fields.
Should I include set codes and collector numbers?
Preserve them in your archive when a specific printing matters. For import, use the format currently accepted by the destination. If identifier syntax creates errors, import by clean card name and make the version choice during preview.
How do I keep maybeboard cards out of the order?
Do not copy them into the cleaned print list. If you want some as test options, move only those chosen cards into a separately labelled extras section and count them outside the playable deck.
Should I print basic lands?
Include basics when you need a complete ready-to-sleeve project or want coordinated versions. Exclude them when you already have suitable lands and are deliberately reducing the batch. Either choice works; the mistake is letting the export decide accidentally.
What should I save after approving the project?
Save the source list, cleaned import file, approved final list, version identifiers for important printings, extras list, date, and change log. Those records turn a future replacement or revision into a controlled small batch instead of a full reconstruction.
Final preflight
Before proceeding, place the preserved Moxfield source beside the imported project. Reconcile the commander, main deck, basics, sideboard, maybeboard exclusions, and extras. Then inspect card versions and special layouts separately. When the structure and the visuals both agree with your records, save the approved list as the reproducible version of the project.