Read exact bytes at the boundary

Suppose a destination accepts 500,000 bytes and your file contains 507,000. A binary display can show about 495.1 KB, which appears lower than 500 while the file still fails. Conversely, a system accepting 500 x 1024 allows 512,000 bytes. The word KB by itself may not explain which rule is being applied; the destination's stated byte count resolves it.

Use the file properties or the tool's measured output rather than rounding the displayed number by eye. For multiple attachments, add the exact sizes before comparing a combined limit. Base64 transport can also be larger than the binary file because it represents three input bytes with four characters before padding and message overhead. A chat or API request limit therefore need not equal the maximum attachment size shown in a file manager. Converting the units helps you reason about the cap but does not alter the file.

Use the same unit as the form

If a portal says the file must be under 300 KB, convert that into MB before checking it in your file manager. If it says 2 MB, convert it into KB before choosing a compression target.

Shard Tools uses the common computer-file conversion where 1 MB equals 1024 KB. That is the convention many operating systems and upload tools use when reporting file size.

Leave a little headroom

A file that appears exactly on the limit can still be rejected if the receiving system rounds differently or adds metadata during processing. For important uploads, aim slightly below the stated maximum.

For example, if a form asks for a PDF under 300 KB, targeting 280 KB or 290 KB is often safer than trying to land exactly on 300 KB.

Convert first, compress second

The converter tells you the number to aim for. Compression tools then do the practical work of reducing an image or PDF toward that target.

Pixel dimensions, page count, image quality, and document readability still matter. A file can fit the size limit while no longer being useful, so always inspect the final output.