Take bytes
Cut out a byte range from a file and keep only that.
Runs on your device. The file is never uploaded.
Take bytes keeps length bytes of a file starting at start, writing them out with -taken before the original extension. start defaults to 0 and length to 16, both whole decimal numbers; hex offsets are not accepted. A range running past the end is clamped rather than padded, so the result can be shorter than you asked for.
Questions
How do I say which range to keep?
With start and length, both in bytes and both plain decimal numbers. start defaults to 0 and length defaults to 16. The output is the bytes from start up to start plus length, so start 512 with length 1024 keeps offsets 512 through 1535. Offsets are the same ones a hexdump shows, converted from hex to decimal.
What if my range runs past the end of the file?
The range is clamped to the file, and you get whatever exists. There is no error and no zero padding, so asking for 4096 bytes from offset 100 of a 200-byte file returns 100 bytes. Check the size of what came back before treating it as a complete extract.
Why was my start or length rejected?
Both fields must be whole numbers of 0 or more. The refusals are "start must be a whole number of 0 or more" and "length must be a whole number of 0 or more". Hex offsets are not accepted, so convert 0x200 to 512 before pasting it in.
What is the output file called?
Your file's name with -taken added before the extension, keeping the original extension, or .bin when the name has none. image.jpg becomes image-taken.jpg. The name does not record the offsets, so note them yourself if you are carving several ranges out of the same file.
Is this how I carve out an embedded file?
It is the manual way, and the accurate one when you know where the payload ends. Find the start offset with Scan for embedded files or Hex viewer, work out the length, then take that range. Extract embedded files automates it but cuts at the next signature match or the end of the file, so its segments can run long.