Picture the person who decides your dispute. They have a queue. Your case is one of dozens they will open today, and they will give it a minute or two, maybe less. They click your evidence and wait while a 38-page scan loads. The first page is a photograph of a monitor, taken at an angle, with a glare across the one line that mattered. They close it and move on.
You were right. You had the proof. And you lost anyway, because the proof arrived in a shape nobody could use.
This is the least glamorous way to lose a chargeback, and one of the most avoidable. It has nothing to do with the strength of your case and everything to do with the container you put it in.
The limits are real, and they are tighter than your camera roll
Stripe restricts what you can attach to a dispute response. There are accepted file types (PDF, JPEG and PNG are the safe ones), a cap on the total size of everything you upload, and a cap on the amount of text you can enter across the evidence fields. The exact numbers have changed over time and differ by field, so check the current figures in the Stripe dashboard or documentation before you build a habit around them. The combined upload cap has historically been in the low single-digit megabytes, which sounds generous until you remember that a single modern phone screenshot can be several megabytes by itself.
Two things follow. First, you cannot dump a folder. Second, and more important, the limit forces a discipline that would improve your evidence even if it did not exist: you have to choose.
There is also a one-shot quality to all this. Stripe lets you submit evidence once per dispute, and you cannot add to it afterward. A file that fails to upload at 11:50 p.m. on deadline day is not an annoyance. It can be the whole case.
Why a smaller, clearer packet wins
The person reading is not you. They did not live through the order. They do not know that the cryptic line in your logs is the moment the customer accepted your terms. Everything in your packet has to be self-explanatory to a stranger moving fast.
This is a matter of cognitive load. People skimming a long stack of material tend to anchor on whatever is easiest to process: the first page, the largest headline, the clearest image. If your strongest proof is on page 31 of an undifferentiated scan, it may as well not exist. Reviewers do not owe you patience, and a document that demands effort to decode quietly signals that the merchant is hiding something or does not know their own case.
A small packet that opens instantly and says one clear thing on each page does the opposite. It reads as organized, and organized reads as credible.
The one-document approach
The most reliable fix is to stop thinking in files and start thinking in a single document. Instead of uploading eleven screenshots, build one PDF in a deliberate order:
- A cover summary of five or six lines: what was sold, when, what the customer is claiming, and the single strongest fact against that claim.
- The core proof, placed immediately after: the signed agreement, the delivery confirmation, the usage log, whatever answers the dispute reason directly.
- Supporting records, trimmed to what corroborates the core proof.
- Nothing else.
One file avoids the failure where three of your five uploads go through and two silently don't. It also guarantees the reading order. You are no longer hoping the reviewer opens the attachments in the sequence you intended.
Making screenshots legible, not just small
Compression is where well-meaning merchants wreck their own evidence. They shrink a file until it fits and discover afterward that the timestamp is a smear. A few principles keep proof readable while keeping it light.
Crop to the evidence. A full-screen capture of a desktop contains your bookmarks bar, a dozen tabs, and a notification from your group chat. Crop to the relevant region. It cuts the file size and removes everything that is not the point.
Capture text as text when you can. Print a web page or email to PDF rather than photographing it. Text-based PDFs stay sharp at any zoom and are often a fraction of the size of an image of the same content.
Keep the identifying details in frame. A screenshot of an email thread proves little if the sender address, date and time are cropped away. Size matters less than provenance: who, what, and when must be visible in the image itself.
Annotate sparingly. One box or arrow pointing at the key line helps a rushed reader. Ten of them turn the page into noise.
Redact what you must. If a record contains someone else's information, black it out before export, and make sure the redaction is flattened into the image rather than a removable layer.
Don't make the reviewer download your life
A tempting shortcut is to paste a link to a shared drive, a hosted log or a cloud folder. Resist it as a primary strategy. The reviewer may not click it, may not be able to access it, or may see a different version than the one you meant. Links can expire or be restricted. Evidence that matters should live inside the packet itself. If you reference something external, treat it as a bonus, never the foundation.
The same logic applies to your written explanation. Keep it inside the text field, in plain sentences, and let the attachments carry the exhibits. Do not paste a wall of text that duplicates what is already in the PDF.
Test the packet like a stranger would
Before you submit, run one check that takes two minutes. Open the finished file on your phone. Not your monitor, your phone, because that is roughly the level of patience and screen space you are designing for. Then ask:
- Can I tell what this is about within ten seconds?
- Is every date and amount readable without zooming in?
- Does the strongest proof appear in the first couple of pages?
- Did the file open instantly?
If the answer to any of these is no, the problem is formatting, and formatting is fixable in minutes.
Your next moves
- Look up the current limits today. Open your Stripe dashboard's dispute evidence section or the documentation and write down the accepted file types, the total upload size, and the text limits. Tape them where you will see them next time.
- Pick a single export tool and learn it. Choose one way to turn screenshots, emails and receipts into one compressed PDF, such as your computer's built-in print-to-PDF or a PDF editor, and practice once on a fake case before a real deadline.
- Build a cover-page template. Write a five-line summary skeleton (item, date, claim, strongest fact, exhibit list) and save it so you only fill in blanks.
- Redo your last lost dispute's packet. Take an old case and rebuild it as one tight PDF under the size cap. Notice what you were tempted to include and what you realize you never needed.
- Submit early. Aim to upload at least a day before the deadline so a failed upload is a small problem you can fix, not a lost case.
Where this gets tedious, and where help fits
None of this is hard, exactly. It is just fiddly work that always lands at the worst moment, with a deadline pressing and a phone in your hand. That fiddliness is the reason good cases get lost. Argeback exists to take that layer off you: it drafts the response from your Stripe dispute data, assembles the evidence into something a reviewer can read, and files it before the seven-day window closes, all from your phone. If formatting is the thing standing between you and a case you should win, you can see how it works at argeback.lumenlabs.works.