Practical design guides
Wedding Place Cards: Keep Names and Meal Codes Matched
A place card can be beautifully typeset and still put the wrong meal marker beside a guest’s name. When every card looks similar, the safest review starts with the guest record and the folded object rather than a decorative mockup.
This workflow uses six fictional adult guests and organizer-approved example codes in a live Ciyo demonstration on November 15. We inspected the six raster cards, a separate folding diagram, returned SVG source text and the CSV mapping. No real guest information, catering instruction or physical print test is supplied.
Quick answer
Approve one guest list with exact display names and any organizer-supplied routing codes. Build and fold a proof using the longest name, then populate the remaining cards from the same source. Review each name-and-code pair together before printing. Do not infer meal meanings, requirements or substitutions from a letter or color.
Input: approve the name and code together
Choose one record per intended card and establish who approves it. Keep display name, table or seat information if needed, and any routing code in separate fields. Do not let a designer recreate the mapping from memory or copy a neighboring card’s code.
In the fictional set, V, F and C are arbitrary organizer-approved routing markers. They are not dietary or allergy guarantees. The event organizer and caterer must define and approve their real meanings and handling instructions outside the visual design task.
A guest’s preferred display name may differ from the spelling used in another planning document. Resolve that before layout, preserving accents and intended punctuation. If two guests have the same display name, the organizer should decide what distinguishes their cards.
| Display name | Approved example code |
|---|---|
| Amelia Rowan | V |
| Benjamin Hart | F |
| Sofia Alvarez | V |
| Oliver Chen | C |
| Nadia El-Mansouri | C |
| Alexander Montgomery | F |
Prototype: test the longest name on a folded card
Choose the actual card format and make a plain-paper prototype. Our example uses a 90 × 50 mm visible face on 90 × 100 mm flat stock folded halfway. These are illustration dimensions, not a universal stationery standard or supplier template.
Begin with Alexander Montgomery rather than the shortest name. Keep a readable type size, adequate edge space and a clear separation from the code. If the name does not fit, reconsider line breaks or the type scale consistently; do not silently shrink only one guest to an unreadable size.
Fold the actual proof and check the reading direction from the guest’s position. The relationship between the flat page, fold and printed faces can be easy to misunderstand on screen. A flat rectangle with correct dimensions does not prove a usable standing card.
Build: keep the source mapping beside the artwork in Ciyo
Give Ciyo the approved records and ask it to preserve each pair exactly. Place a compact source table beside the card previews, with a clearly marked proof for the longest name. A canvas is useful for reviewing the set together, but the table remains the authority for matching.
Request the source and output formats required by the person preparing the print run. Confirm the files actually delivered and whether text remains editable. A rendered card image does not prove a native editable layout or a correctly imposed printer sheet.
For a small event, a manual pair-by-pair review may be sufficient. For a stationery studio preparing a larger set, use a data-driven layout tool that can repeat a proven template, then inspect the generated records. Avoid turning a design prompt into an unverified catering database.
The live result contained six 1063 × 1181 raster previews and a separate 2079 × 1843 folding diagram for Alexander. Ciyo returned complete SVG source text for all six cards and a CSV, which we saved as files. Parsing the sources confirmed 90 × 100 mm artboards; the name artwork is translated into the lower 50 mm panel, with its top toward the fold. Every name and code matched the six source records, including Nadia El-Mansouri’s hyphen.
Nadia and Alexander use two name lines. The observed raster previews fit, but the SVG text depends on EB Garamond or a fallback font, so the recipient must recheck line width in the actual application. The cream background is printed artwork, not unprinted paper. The fold is documented in a comment rather than drawn on each production master; the separate diagram is a screen review, not a physically folded proof.
Create folded place-card proofs for these approved fictional or authorized records: [DISPLAY NAME, ROUTING CODE]. Format: [VISIBLE FACE AND FLAT STOCK DIMENSIONS]. Preserve every name and code exactly, keep the longest name readable and show the folding direction on a separate proof. Place the source mapping beside the previews. Do not infer dietary needs, code meanings, seating changes or substitutions. Return only supported files and state any missing editable or print handoff.
Review: reconcile every card against the list
Read each finished card beside its source row. Confirm the name, accents, code and any table identifier. Count the cards and compare the count with the approved records. A complete-looking grid can still contain a duplicate and a missing guest.
Ask a second reviewer to check the mapping without relying on the layout creator’s memory. If the event team changes a code, update the source row first, regenerate the affected card and repeat the pair check. Check the replacement within the complete set so an obsolete version is not left in the print folder.
Do not add a code to a card just because its color looks balanced. Codes are information supplied by the organizer. If a mapping is missing or ambiguous, hold that card for clarification rather than inventing an answer.
Output: proof, print and sort deliberately
Use the printer’s current requirements for trim, fold, stock and sheet layout. Provide a clean production file and a separately identified folding proof if needed. Test the actual stock and fold before producing the full set; no physical print test is claimed here.
Keep the final count, version and sorting instructions with the handoff. The setup team may need cards grouped by table while a stationery designer prefers alphabetical review. Agree on the final sequence rather than assuming the canvas order is the placement order.
Use a seating chart when guests need help finding a table; use place cards to identify a specific setting. Those deliverables can share approved records, but they answer different questions and need separate layout checks.
Questions about wedding place cards
Are place cards the same as a seating chart?
No. A seating chart helps guests find a table or assignment; a place card identifies a particular setting. Agree on which deliverable your event needs.
Can the designer decide the meal codes?
The organizer and caterer supply and approve the real mapping. The example letters are fictional routing markers and imply no dietary meaning.
Should I make every long name smaller?
Test the longest name first and choose a consistent readable treatment. Consider deliberate line breaks or layout changes rather than unreviewed per-card shrinking.
Does the flat layout prove it folds correctly?
No. Print a plain-paper proof, fold it and inspect the orientation from the guest’s position before ordering the run.
Proof the longest name first
Bring an approved name-and-code list into Ciyo. Review a folded prototype and the complete mapping before preparing the print set.