Resume ASCII Conversion Experiment: Object Lesson

Converting formatted Word documents to ASCII is confusing

Because ASCII (plain text) conversion for resumes sent within e-mail messages is so critical and common to current practice, I now include it as a service for resume writing clients. Everyone has e-mail now, and hiring managers are no exception. It’s your job to make sure that what you send to them in the body of your e-mails is as readable as what you see on your own screen. For this reason, you need to convert your resume to ASCII, or plain text before copying into the body of your e-mail. Otherwise, what you send inevitably will not be what your receiver reads—he or she will simply get a messy document that takes too much time to sort out. Your potentially excellent message will be lost in the medium, and your resume will wind up in the trash.

To prove the value of ASCII conversion, I did a test case and sent myself a variety of e-mails containing a few different resumes I wrote for clients, just to see how they convert. I learned a lot from this experiment. Overall, the conversion is poor, and it largely depends on the settings that the reader has determined, ranging from font set to reading preferences (HTML vs. plain text) as well as the e-mail client (reader) the person is using. In other words, the only predictability in the output was that it was, well, unpredictable.

The following are the types of errors I discovered in my quest.

Font Conversion
The bullets and special characters turned into odd-looking wingdings or foreign alphabet characters that I didn’t choose in my original design. Because you don’t know what font set the reader will have on his or her e-mail, you have to assume that the font conversion will be messy and unpredictable at best. The result is a hodgepodge of characters that might or might not correlate to what you actually intended to write.

Display
All of the formatting was lost. Tabs, spacing, text formatting, font, everything. The only element that was retained in the conversion was capitalization. In a good resume design, the resume writer uses underlining, bolding, italics, and indenting to clue the reader into what is important. That element was completely lost in the test case, which made the document look like a long, bland page of undifferentiated text.

Rules (lines between sections) showed up in my test e-mails, but not necessarily how I designed the original resume. You can guarantee that if you don’t convert your document to ASCII properly, what you had centered or shaded will appear at the whim of your recipient’s e-mail client (reader). Whatever the settings are on the reader’s end are what will determine the way your resume appears. It’s guaranteed it won’t look like your lovely formatted Word version.

Paragraphs were included as one long line with no text wrapping. This is simply unpleasant to read—one should not have to scroll horizontally to read the whole message.

Spacing after paragraphs was unpredictable and often too deep. These kinds of spacing errors are messy and unappealing—and they take up extra page space when your resume is printed.

Footer and Text Box Information Is Lost
In my test case, the address was in the footer, and the e-mail and phone number were included in a text box at the top of the document. Both were lost in the conversion. A hiring manager won’t be able to contact you if you don’t appear to have included your key contact information.

Conclusions from My ASCII Experiment

The foregoing list of errors is from a cursory review of the e-mails I sent to myself—there might be other errors that your system, or your recipient’s system injects that neither you nor I could predict now. There are simply too many variables. Therefore, I suggest that if you are sending your resume via e-mail, you need to learn to convert to ASCII and present your resume well.