Attachments make some conversations dramatically shorter. A screenshot settles a bug report that would otherwise take ten messages of description, and an order confirmation resolves a billing question instantly.
They also come with a set of rules that are not obvious from the settings screen, and the gap between what admins think they configured and what the server actually enforces produces a steady trickle of confused tickets. This guide is about the mechanics: what gets through, what does not, and why.
Every attachment passes two gates
An uploaded file is checked twice, and both checks happen on the server rather than only in the browser. One gate is the file size. The other is the file extension.
Both have to pass. A small file with a disallowed extension is rejected, and a permitted file type that is too large is rejected too, with a different error. Knowing which of the two stopped a file is most of the work in diagnosing a failed upload, and the message the visitor receives distinguishes them.
The size cap scales with your plan
The maximum attachment size is a function of your licence tier rather than a single global number. It starts at one megabyte for trial, free and expired accounts and rises through the paid tiers, reaching twenty megabytes at the top. An account on a plan the system does not recognise falls back to a conservative default rather than to the largest value.
You do not have to look the number up or trust it from a document, and you should not. When a file is too big, the rejection message includes the actual limit for your account, formatted for humans. That message is generated from the same value the server enforces, so it cannot drift away from reality the way a published figure can.
The same limit is also handed to the widget so it can check before uploading. That is a convenience rather than a second opinion; it exists so that a visitor dragging in a large file learns immediately instead of after a long upload. The server check is the one that decides.
How the file type list is read
The allowed file types setting is a list of extensions. It is tolerant about how you write it: separators can be commas or vertical bars, leading dots are ignored, surrounding spaces are trimmed, and matching is case-insensitive. Writing .PDF and pdf produces the same result.
An asterisk on its own, or the older *.* form, means accept anything. Those are the only wildcards; you cannot write a partial pattern such as doc* and have it match several extensions.
A file with no extension at all is rejected before the list is consulted. There is no way to permit extensionless files through this setting.
A blank list does not mean one thing
This is the rule most worth internalising, because it is genuinely asymmetric and nothing on the screen hints at it.
If you leave the allowed types list empty, uploads during a live chat are accepted regardless of type. Empty means unrestricted on that path, which is legacy behaviour retained so that existing accounts did not suddenly start rejecting attachments.
On the offline message form, an empty list means something different. There it falls back to a built-in default set covering common images, PDFs, the usual office document formats, plain text and zip archives. So the same blank field yields an open door in one place and a curated list in another.
The practical advice follows directly: do not leave it blank and assume you have a policy. If you want a restriction, write it. If you genuinely want everything, write the asterisk, so the next administrator can see that it was a decision rather than an omission.
Spreadsheets get through regardless
There is one carve-out that overrides your list entirely. Excel and CSV formats are always accepted, even when your allowed types list does not include them and would otherwise reject them.
This exists for a sensible reason. Many accounts configured their list before spreadsheet uploads were supported, and without the carve-out those customers would have found ordinary business attachments bouncing for no visible reason.
The consequence is still worth stating plainly: you cannot use the file type list to block spreadsheets. If your reason for wanting to is that spreadsheets are a common vehicle for macro-based attacks, the list is not the control you need, and the answer lies in how those files are handled after they arrive rather than in whether chat accepts them.
An extension is not a content check
Everything above is string matching on a filename. None of it inspects what is inside the file.
A hostile file renamed to end in a permitted extension passes the extension gate exactly as a legitimate one does. This is not a weakness peculiar to chat; it is true of every extension-based filter anywhere. It just means the list should be understood as a way of reducing accidental noise and setting expectations, not as a defence.
The controls that matter for genuinely hostile files live downstream: what your agents are trained to open, what their machines do with a downloaded file, and where the file is stored afterwards. Those are covered properly in our companion guide on attachment safety, and they deserve more attention than the list does.
Setting it up deliberately
Start from what your agents actually need to do their job. For most teams that is screenshots and PDFs, and adding office documents covers nearly everything else that legitimately arrives.
Write that list explicitly on both the live chat and offline paths, so the two behave the same way and neither is relying on a fallback you have not thought about. Then send yourself a test file of each type you expect, and one you expect to be refused, so you have seen both outcomes with your own eyes.
Revisit the list when your product changes. Teams that start supporting a new file format usually update their help content and forget the upload settings, and the symptom is a customer who cannot send you the one file that would answer your question. Chat that handles this well pairs naturally with the rest of your live chat setup.
What to measure
Count failed uploads if you can see them, and read a sample rather than only the total. Repeated rejections of the same extension are a configuration signal, not a visitor problem.
Listen for the workaround. When visitors start pasting links to file-sharing services, or describing a screenshot in words, your limits are tighter than the work requires and people are routing around them in ways that are worse for everyone.
Track how often agents ask a customer to resend something in a different format. That request is cheap once and corrosive as a pattern, and it usually points at a list written years ago by someone who is no longer deciding what support needs.