If won't damage your DB, but it may "damage" the performance.
Your could SHRINK and then REINDEX everything. If you get back to the original MDB size then that's the "working-size" that you need (and you will have fragmented the file, a bit, in the process).
As I said earlier ("I would check the slack space on all the tables.") it would be worth seeing how much free space there is within the tables (as compared to "space at the end of the file to allow for future expansion"
As you add more content the database will grow. If you rebuild an index SQL may use fresh space, at the end of the file (including extending the file if necessary) to make a nice, contiguous, index. But the space where the old index was will then be reused, so over time the file will reach equilibrium (just growing in proportion to the new data that you add)
If your file is 8GB and only contains a few MB of "content" then clearly the DB could be shrunk a lot smaller.
If your file is 8GB, contains 7GB of data and of that only a few MB is "slack space" within the tables, then it is pointless to try to shrink it.
An 8GB file, with 7GB of data but the tables containing, say, 6GB (i.e. "a lot") of slack space would indicate that something needs optimising.
If you don't have Clustered Indexes on ALL Tables then SQL may struggle to keep-a-lid on the space usage, because "rebuild" may not do a thorough job (answer: create a clustered index if it makes sense to do so - there are some occasions where it is preferable to just have a Heap table; the only alternative that I know of is to export all the data and re-import it "clean" (but I expect there is a better way, we don;t have any Heap tables in our systems), so better to create Clustered Indexes if possible).