Restored database copy larger than original
You may find this surprising but this is something I have come to expect often. I have mentioned in other posts how data loaded in primary key order can populate BTREE indexes in a lopsided manner:

May 01, 2014 : Why would the size of MySQL MyISAM table indexes (aka MYI file) not match after mysqldump import?
Dec 28, 2014 : What are the optimal mysqldump settings? (See the CAVEAT about --order-by-primary)

This behavior is seen for MyISAM and InnoDB alike. Don't be too alarmed by this. If the data being copied is in order by an auto-incremented primary key when dumping, the clustered index is populated in a lopsided manner from inception.
When it comes to InnoDB, bulking loading data into a table with an index will have a degree of fragmentation introduced. You just have to bite the bullet on this.
To minimize this, you should do the following for table mytable:

Copy the table schema for mytable
Create empty mytable on target server
Drop indexes for mytable on target server
Load data into mytable on target server
Create all indexes

MyISAM already has this paradigm in place for non-unique indexes when reloading MyISAM tables

ALTER TABLE mytable DISABLE KEYS;
Load the data
ALTER TABLE mytable ENABLE KEYS;

InnoDB does not :-(
CONCLUSION
Your main concern should be the content of data.
You should run pt-table-checksum for the table for both source and target servers. Even with mismatches here, do not worry too much with VARCHAR columns (See my post Native checksum table says there&#39;s a difference, pt-table-checksum does not).
You could also just dump the data in a specific into CSV files on source and target servers and compare the text just to inspect content.
In closing, even though the table is small, once the copy is done and the table is not corrupt, try what you reasonably can to defragment your tables and just live with it.