Hex file size depending on programmer software for PICkit 3

Is the chip erased before download? Pickit software itself does not generate code (hex files), just send what is in the hex file that was created by the compiler. However, if the Pickit thinks the chip needs erasing, it will insert (?) the FF code for the rest of the programmable space to clear old code.
It might be an option or check box somewhere in the programmer itself, not sure.
What I see are identical "code" in both files, and "FF" added for areas of the PIC that do not have code for it in the Pickit minus file.
If this is a reading back of the PIC, again it may be an option or the Pickit minus simply reads the entire chip because it cannot know where the code ends and blank space begins.
Start by looking at the hex file produced by the compiler only. It will be the smaller size. Then look at options for programming the chip itself and whether it is pre-erased.

I don't quite understand the question: "Is the chip erased before download?"
Dowwnload what? Do you mean "Write"?
I always "Erase" and "Blank Check" the chip before I "Write" to it.
The large hex file is a "Read"-back of the compact hex file created with the compiler.
I am attaching a screenshot of the file compare result with the file explorere "Total Commander v9.51".
Beginning in line 235 all the way down to end of file there is a huge amount of unnecessary code that blows up the file size. - As I said before, I can live with that.

Ok, it is the read back of the chip that created the larger hex file. Since the programmer/reader does not know where the code ends (it cannot interpret the bytes), it will simply read the entire PIC chip program space. Any PIC you read, the reading program will always read the entire chip unless there is an option to read only a portion.
Also there is in Pickitminus an option under "Tools" that skips blank sections. Not sure if that will help or not...
But bottom line, if reading a PIC chip (readback), it will usually read the entire chip, including the blank areas.

Thank you for the explanations. - I want to remeber in the future.
As an addendum, please look at the screenshot take from the end of file.

Those are likely the configuration bits of the PIC you are reading... But they seem to be at strange addresses. It could be the way you are reading the PIC

I checked again and compared the files read from the same PIC with the same hex content.
- Image1.png shows the file that has been programmed into the PIC (red) and the two files read with US-Burn and PICkitminus respectively.
- Image2.png shows the file comparison PIC content vs read from the PIC.