Yes, you can shrink it to (close to) 20GB, but I wouldn't recommend it.
Instead, pick reasonable target sizes, with sufficient free space, for the data and log file individually. Give SQL some "elbow room", if you will.
In your case, I'd suggest, say, a 25GB data file (20% free space), and also probably a 5GB log file (which could vary depending on expected activity, and whether you are using simple or full recovery mode).
@rollstuhlfahrer's answer about how to do that is correct: use the "Shrink File" feature so you can be specific about your target size, not "Shrink database".
WARNING: Shrinking should never be routine or scheduled, it should be a rare event in response to a specific need (like in your case, to recover an initial over-allocation).
WARNING 2: Shrinking tends to fragment tables, I'd recommend doing a reindex after your shrink operation, which may reclaim some of the space you've just freed. If it does, just leave it at that size.
.mdf
file mentioned. That means, there is an MS SQL Server involved. – rollstuhlfahrer Jan 18 '18 at 10:04