I'm searching for a short term of "Convert data to bytes".
It has to be a verb, because it should tell that it's a operation.
I thought of something like "byteify" - but that looks ugly to me...

The conversion I'm talking about is, for example, from a 32 bit floating point value like 567.89, or a string like "123.4", to an array of bytes as output.

Same conversions for any other type (int, short, ...).

  • 2
    @RegDwigнt I'd answer if it would be reopened - "serialize" is exactly what he means, now it all makes sense! Aug 4, 2014 at 9:45
  • @VolkerSiegel: Don't worry. String number is something like "12.4" as string. And yes, the function takes a string as input and always outputs a byte array. The real type only tells how the convertion is done. Sorry - its hard for me to formulate a quesition. "Serialization" is correct, but I'm still searching for a term that says "you will get a bunch of bytes". Serialization is too broad.
    – joe
    Aug 4, 2014 at 10:34
  • Hmm... to me, serializeFloat(float aFloat) exactly means I get a byte array for my input. In the big picture, you "serialize the data structures to a stream of bytes", but practically, for one object, you get an byte array, that is "the next piece of the stream". Aug 4, 2014 at 10:39
  • Oh, I proposed it, but missed that it was reopened. Now I added an answer explaining the word by explaining what is serial about the serialization. Aug 16, 2014 at 19:32

4 Answers 4


Serialization is the process of turning object/data structures into a storage format. Serialize is the verb form. To bytes specifically is binary serialization. To a string is stringification or to stringify as listed in the other answer, as well as this (closed) programmer SE question.

  • Yes, one should use the correct word!
    – user63230
    Aug 5, 2014 at 23:33

As I see it, you are trying to take a statement:

convert from format A to format B

and find a word that conveys both "convert" and "format B" at the same time. Almost every word (stringification aside) that I've seen only covers the "convert" part, and leaves the final format unsaid, to be understood by context or convention. This is not as horrible as it sounds, because your "format B" is "a byte string", but you are not going to mention in the name which way you are converting it to a byte string. You're always going to have to leave something out of your name.

If you are willing to give up on having "byte string" explicitly in the word, the shortest one I have seen is "pack", at only 4 letters. It also has a nice reverse name, "unpack", and has been used in many programming language libraries to mean "packing into a string of bytes".

  • In one sense, this question is a programming question instead of a language question and in that sense, this is the correct answer.
    – TecBrat
    Aug 6, 2014 at 10:09

TL;DR You stringify objects and encode strings — but this is not an English question.

Greener Pastures

This question probably should not be here, because it does not appear to be English question as all. It appears to be a programming question, and so should be on moved to an SE site that is actually about programming. Programming questions are off-topic here.

Converting data to bytes — or to bits — is a very loose description. What kind of data? You mention 32-bit floats, such as you might do with the printf family of functions. Then again, a 32-bit quantity could be represented as four dotted octets, like

Encode Strings

If you have a logical string that’s being used internally some programming language which you are converting to some external interchange format, then that conversion process is known as encoding your string, such as encoding it in MacRoman or ISO 8859-1, or UTF-8 or UTF-16, et cetera.

When you read in a string from its external representation, you decode it and store it as the logical string object in whatever programming language you’re using. When you write it out again, you encode it from the logical form into some physical form for external interchange.

If you need something tailored to your programming language, those words surely already exist.

Stringify Objects

If what you have is just some random object needing to be externally representable, then you seem to be looking for marshal (which nobody will understand) or stringify (which they will):


The process of producing a string representation of an abstract object.
                ―page 1076 of Programming Perl, 4th edition, by Christiansen et al., O’Reilly 2012

Stringify should be preferred over serialize, especially in cases where confusion might arise from its antonymic association with parallelize.

No one will ever know what marshal means, nor be certain of serialize. But of stringify there can be no doubt.

For Programmers Only: Mythbusting 123.4 as a 32-bit float

Whenever you see somebody talking about floating-point numbers (rather than real numbers) like 567.89 or 123.4, they are speaking in an extremely fuzzy and off-the-cuff manner, because those numbers aren’t really there on your computer. This makes whatever conversion process you care to use fuzzy as well.

This is odder than it appears.

Real numbers like 567.89 and 123.4 cannot be exactly represented in 32-bit floating point. That means that whatever your “convert to bytes” notion is, it is going to have to involve either some rounding or else some rather interesting-looking bytes.

Assuming IEEE 754, the closest you can get to the real number 123.4 is something that looks more like 123.400002, or without slop exactly 0x1.ed999ap+6 in hexadecimal floating point notation. Similarly, the closest you can get to the real number 123.3 is floating point 123.300003 or 0x1.ed3334p+6, and the closest you can get to 123.6 is 123.599998 or 0x1.ee6666p+6.

That’s because none of the rational numbers 3/10, 4/10, and 6/10 reduce to a fraction whose denominator is a power of two. So you get slop.

However, 123.5 can be represented exactly, because 5/10 is 1/2, and 2 is obviously a power of 2. So the real number 123.5 is exactly represented by the float 0x1.eep+6. Notice there is no slop there: just 0xEE.

To convert the 32-bit floating point number that’s closest to the real number 123.5 into bytes, you could get away with the four bytes which when read as characters in ISO-8859-1 are “ÍÌöB”. This makes sense: 32 bits is 4 bytes, and 4 bytes are 4 bytes. If you looked at those four bytes as an IP address, they could be

Since we don’t have real numbers here, merely floating point approximations, strange things happen if you aren’t careful. For example, although multiplying floating-point 123.4 by 10 produces 1234 (which is hex 0x1.348p+10 in floating point), adding it together 10 times does not: it instead produces 0x1.348002p+10, which is actually more like 1234.000122 instead of 1234.

Yes, it’s a bit off, but these are closer together than you might think. Via direct multiplication, the octets (on my machine, and probably yours) are, but the one you get via tenfold summation are The low bit of the significand is different. So not only is it a bit off, it is exactly one bit off.

To see how this works, merely compile this trivial C program in C99 mode:

#define ITER 10    
#include <stdio.h>
#include <stdlib.h>
#include <stdint.h>    
#include <arpa/inet.h>

void cracker(FILE *output, float fnum);

main(int argc, char **argv, char **envp) {    
    FILE *iconv;    
    if (!(iconv = popen("iconv -f ISO-8859-1 -t UTF-8 | LESSCHARSET=utf-8 less", "w"))) {

    cracker(iconv, 567.89);    
    float f = 123.4;
    fprintf(iconv, "Starting point:\n");
    cracker(iconv, f);

    float sum = 0;
    for (int i = 0; i < ITER; i++) {
        sum += f;

    fprintf(iconv, "Added together %d times:\n", ITER);
    cracker(iconv, sum);
    fprintf(iconv, "Multiplied by %d:\n", ITER);
    cracker(iconv, ITER * f);

    cracker(iconv, 123.3);
    cracker(iconv, 123.4);
    cracker(iconv, 123.5);
    cracker(iconv, 123.6);


cracker(FILE *output, float fnum) {

    union {
        float          fn;
        uint32_t       un;
        unsigned char  octets[4];
    } polly;

    polly.fn = fnum;

    struct in_addr in;
    in.s_addr = htonl(polly.un);

    fprintf(output, "Your hex float is   %a\n", polly.fn);
    fprintf(output, "Your     float is   %f\n", polly.fn);
    fprintf(output, "Your   rounded is   %g\n", polly.fn);
    fprintf(output, "Your   hex int is   0x%X\n", polly.un);
    fprintf(output, "Your    octets are  %s\n", inet_ntoa(in));
    fprintf(output, "Your     chars are \"%c%c%c%c\"\n\n",


And then run it to get this output:

Your hex float is   0x1.1bf1ecp+9
Your     float is   567.890015
Your   rounded is   567.89
Your   hex int is   0x440DF8F6
Your    octets are
Your     chars are "öø^MD"

Starting point:
Your hex float is   0x1.ed999ap+6
Your     float is   123.400002
Your   rounded is   123.4
Your   hex int is   0x42F6CCCD
Your    octets are
Your     chars are "ÍÌöB"

Added together 10 times:
Your hex float is   0x1.348002p+10
Your     float is   1234.000122
Your   rounded is   1234
Your   hex int is   0x449A4001
Your    octets are
Your     chars are "^A@<U+009A>D"

Multiplied by 10:
Your hex float is   0x1.348p+10
Your     float is   1234.000000
Your   rounded is   1234
Your   hex int is   0x449A4000
Your    octets are
Your     chars are "^@@<U+009A>D"

Your hex float is   0x1.ed3334p+6
Your     float is   123.300003
Your   rounded is   123.3
Your   hex int is   0x42F6999A
Your    octets are
Your     chars are "<U+009A><U+0099>öB"

Your hex float is   0x1.ed999ap+6
Your     float is   123.400002
Your   rounded is   123.4
Your   hex int is   0x42F6CCCD
Your    octets are
Your     chars are "ÍÌöB"

Your hex float is   0x1.eep+6
Your     float is   123.500000
Your   rounded is   123.5
Your   hex int is   0x42F70000
Your    octets are
Your     chars are "^@^@÷B"

Your hex float is   0x1.ee6666p+6
Your     float is   123.599998
Your   rounded is   123.6
Your   hex int is   0x42F73333
Your    octets are
Your     chars are "33÷B"

As I said, either you will have to do some rounding or else you are going to have to get some rather curious-looking bytes, as the chars display eventually shows above after it has been run through several backend converters so you can see what they look like without squinting too terribly badly.

  • 2
    In many contexts there could be plenty of doubt. There are multiple ways to byteify a string. Strings are not always strings of bytes. They are often strings of characters.
    – Dan Getz
    Aug 5, 2014 at 23:01
  • Stringify a string? I think not.
    – user63230
    Aug 5, 2014 at 23:31
  • 1
    @andy256 Well, then you’d be wrong. Even a string is an abstract object. The internal representation is “secret”, the external interface to that string a logical one based on code points, not on bits and bytes. Stringification lays those out in a physical fashion, which for something like a CP1252 or UTF-8 or UTF-16 output stream, is considerably different than the internal representation of the object.
    – tchrist
    Aug 6, 2014 at 0:38
  • @DanGetz Yes, a string is still an object with its own internal representation. Converting that into an external representation, like you would do for writing to a file, produces a completely different thing: the conversion is from a logical to a physical representaiton.
    – tchrist
    Aug 6, 2014 at 0:40
  • I think you are thinking of a particular class of programming languages. The OP hints at C-style languages, but nothing more specific than that.
    – user63230
    Aug 6, 2014 at 1:06

We do not know what the resulting "bytes" will be used for, but I assume they are going into some "linear data transport", like a network connection.

The important thing is: you have structured data objects in the memmory of you process, and need them in a linear for - as a series of bytes:

What you do is to "serialize" the data.

Serialization is the conversion of structured instances of data to a series of bytes as a linear form. It's not really an array of bytes, it's conceptually an infinite "stream" of bytes, or even bits only.
The point is that is has no explicit structure.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.