Actual content of a symlink file

You didn't provide additional details, so this explanation is for the moment centered on the EXT file systems common in Linux.

If you look at the "size" of a symlink as provided by e.g. ls -l, you will notice that the size is just as large as the name of the target it is pointing to is long. So, you can infer that the "actual" file contains just the path to the link target as text, and the interpretation as a symbolic link is stored in the filetype metadata (in particular, the flag S_IFLINK in the i_mode field of the inode the link file is attached to, where also the permission bits are stored; see this kernel documentation reference).

In order to improve performance and reduce device IO, if the symlink is shorter than 60 bytes it will be stored in the i_block field in the inode itself (see here). Since this makes a separate block access unnecessary, these links are called "fast symlinks" as opposed to symlinks pointing to longer paths, which fall back to the "traditional" method of storing the link target as text in an external data block.

That's totally file system dependent.

Usually the the symlink target is stored as-is within the extra space of an inode block, the same way small directories and small files are. There's no need for any special data format -- the file mode bits already determine that it's a symlink and should be treated as such. The target is the "actual content": you can use readlink -n /path/to | hexdump if you really want to use hexdump.

When calling lstat(2) on a symlink, st.st_size will contain the length of the target (not including any terminating NUL byte).

Using hexdump on the symlink is not looking at the ext4 filesystem at all. It's looking at the application-facing abstraction. At this layer there is nothing to see. Opening the symlink will either attempt to open what it refers to according to path resolution semantics (no O_NOFOLLOW) or fail (O_NOFOLLOW). The way to read the contents at this abstraction layer is readlink, and it will simply give you the sequence of bytes that were passed to symlink to create it. This does not tell you anything about how it's represented on disk.

To examine the representation on disk, you need to open (or use a tool that opens) the block device, and walk the filesystems structures til you get to the symlink you want to see. I believe ext4 stores small-content symlinks inline in the inode structure (no separate data block on disk) and stores large ones merely as a file containing the link contents, but with type symlink.