You will find that every time you make a change or add to the database as you are designing it the size grows disproportionately. Compact regularly - this not only keeps the size down but ensures all the deleted stuff gets removed.
If there's one "cardinal trade-off" in computers it is ... speed vs. space.
Quite frankly, space is very cheap now but speed is as precious as before. Microsoft Access does not go out of its way to "garbage collect." It does not try to make the filesize as small as possible. It does not try to shrink the file, because that is expensive in most filesystems. It will do so, but only when it must.
You can compact a database, but I very rarely do. Just leave it alone and allow it to be as large or as small as it cares to be. The format is designed to be entirely self-maintaining.
Sorry but, I must disagree. An access DB should be compacted regularly. As you develop the DB thr objects becoming bloated are the system object that typically you do not see, though you can select to.
When changes are made to the DB the sytem objects keep track of these changes. So if you delete three forms the sytem still has all the information for those forms tucked away. Compacting and repairing will clear out any this data. your application will run better and be less likely to have errors for seeming no reason.
PS: space is cheaper than it used to be. 10 vs. 20 MB is not a huge deal untill you need to have users dowlload that difference. 100 GB vs. 200GB IS a big deal, keeping a DB streamlined now is a good habit when you move u to the big boy DB's.
I agree with Darasen, but my experience is slightly different. I programmed a database that uses humongous tables, and I notice that when some queries run - the returned recordsets are similarly huge - Access allocates the space needed, but when the query is closed, the space does not get de-allocated. Hence, the database grows larger and stays that way. Regular compacting is the only way.