Swap endianness

The byte order inside each fixed-size word. With wordSize 4, the default, bytes 0 to 3 are written back in the order 3, 2, 1, 0, then bytes 4 to 7, and so on to the end. It does not reverse the file and it does not reorder words relative to each other. Choose 2, 4 or 8 to match the field width of the data you are looking at.

The leftover bytes are copied through unchanged, and the tool tells you so with a note that a trailing count of bytes did not form a full word and were left unchanged. They are not padded and not dropped, because either choice would change the file length or invent bytes that were never there.

Your file's name with -swapped inserted before the extension, keeping the original extension, or .bin if the name had none. data.raw becomes data-swapped.raw. Nothing else about the file changes, so the output is exactly as long as the input and holds exactly the same bytes in a different order within each word.

Only if the cause was byte order, which is common with raw dumps from a device of the opposite endianness and with 16-bit audio or sample data. It cannot fix truncation, corruption or a wrong offset. Swap it, then run Detect file type or Hex viewer on the result; if a known signature appears, the byte order was the problem.

Yes. Running it again with the same word size gives back the original bytes exactly, including any trailing partial word. That makes it safe to try each of 2, 4 and 8 on a copy and keep whichever produces something recognisable.