ในระบบเครือข่ายคอมพิวเตอร์ระบบจะเรียกว่า " สะอาด 8 บิต"หากสามารถประมวลผลการเข้ารหัสอักขระ8 บิตได้ โดยไม่เปลี่ยนแปลงบิตสูงสุดหรือถือว่าไบต์ ใด ๆ เป็น รหัสควบคุม แบบอินแบนด์คุณสมบัตินี้สามารถใช้อธิบายได้ทั้งโปรโตคอลการสื่อสารและซอฟต์แวร์และอุปกรณ์ที่ใช้โปรโตคอลดังกล่าว แม้ว่าระบบอีเมลในยุคแรก ๆ จะรองรับข้อมูลเพียง 7 บิต แต่ระบบอีเมลสมัยใหม่ส่วนใหญ่เป็นระบบ "สะอาด 8 บิต"

จนกระทั่งต้นทศวรรษ 1990 โปรแกรมและช่องทางการส่งข้อมูลจำนวนมากยังคงใช้ระบบอักขระเป็นหลักและถือว่าอักขระบางตัว เช่นอักขระสิ้นสุดข้อความ (ETX) เป็นอักขระควบคุมบางระบบใช้ระบบอักขระเจ็ดบิตที่มีค่าระหว่าง 0 ถึง 127 ตัวอย่างเช่น มาตรฐาน ASCIIใช้เพียงเจ็ดบิตต่ออักขระหลีกเลี่ยงการแสดงผลแบบแปดบิตเพื่อประหยัดค่าใช้จ่ายในการส่งข้อมูล ในคอมพิวเตอร์และลิงก์ข้อมูลที่ใช้ไบต์ 8 บิตบิตบนสุดของแต่ละไบต์จึงว่างไว้สำหรับใช้เป็นบิตพาริตีบิตแฟล็กหรือบิตควบคุมเมตาเดตา ระบบและลิงก์ข้อมูลเจ็ดบิตไม่สามารถจัดการกับรหัสอักขระที่ซับซ้อนกว่าได้โดยตรง ซึ่งเป็นเรื่องปกติในประเทศที่ไม่ใช้ภาษาอังกฤษที่ มี ตัวอักษร ขนาดใหญ่กว่า

ไฟล์ไบนารี ที่ประกอบด้วย อ็อกเท็ต 8 บิตไม่สามารถส่งผ่านช่องสัญญาณข้อมูล 7 บิตได้โดยตรง เพื่อแก้ไขปัญหานี้ จึง มีการคิดค้น การเข้ารหัสไบนารีเป็นข้อความ โดยใช้เฉพาะอักขระ ASCII 7 บิตเท่านั้นการเข้ารหัสเหล่านี้บางส่วนได้แก่uuencoding , Ascii85 , SREC , BinHex , kermitและBase64ของMIME ระบบที่ใช้ EBCDIC ไม่สามารถจัดการกับอักขระทั้งหมดที่ใช้ในข้อมูลที่เข้ารหัสด้วย UUencoding ได้อย่างไรก็ตาม การเข้ารหัส Base64 ไม่มีปัญหานี้

ในอดีต มีการใช้สื่อหลากหลายประเภทในการส่งข้อความ ซึ่งบางประเภทนั้นรองรับข้อมูลเพียง 7 บิตเท่านั้น ดังนั้นข้อความ 8 บิตจึงมีโอกาสสูงที่จะผิดเพี้ยนระหว่างการส่งในศตวรรษที่ 20 บางระบบจึงไม่สนใจข้อห้ามอย่างเป็นทางการเกี่ยวกับการส่งข้อมูล 8 บิต และอนุญาตให้ไบต์ที่มีบิตสูงสุดส่งผ่านได้ ระบบดังกล่าวเรียกว่าระบบที่ "สะอาด 8 บิต" โดยทั่วไปแล้วโปรโตคอลการสื่อสารจะเรียกว่า "สะอาด 8 บิต" หากมันส่งผ่านบิตสูงสุดของแต่ละไบต์ในกระบวนการสื่อสารได้อย่างถูกต้อง

มาตรฐานโปรโตคอลการสื่อสารในยุคแรกๆ หลายมาตรฐาน เช่นRFC  780 , 788 , 821 , 2821 , 5321 (สำหรับSMTP ), RFC 977 (สำหรับNNTP ) และRFC 1056ได้รับการออกแบบให้ทำงานบนลิงก์การสื่อสาร "7 บิต" ดังกล่าว โดยเฉพาะอย่างยิ่งกำหนดให้ใช้ ASCII "ส่งเป็นไบต์ 8 บิตโดยที่บิตลำดับสูงสุดถูกล้างเป็นศูนย์" และบางมาตรฐานเหล่านี้^{[ 1 ]}จำกัด ข้อมูล ทั้งหมดให้เป็นอักขระ 7 บิต อย่างชัดเจน  

ในช่วงไม่กี่ทศวรรษแรกของเครือข่ายอีเมล (ตั้งแต่ปี 1971 ถึงต้นทศวรรษ 1990) ข้อความอีเมลส่วนใหญ่เป็นข้อความธรรมดาในชุดอักขระ US-ASCII 7 บิต^{[ 2 ]}

คำจำกัดความของ SMTP ใน RFC 788 เช่นเดียวกับ RFC 780 รุ่นก่อนหน้า จำกัดอีเมลอินเทอร์เน็ตไว้ที่บรรทัด (ไม่เกิน 1000 ตัวอักษร) ของอักขระ US-ASCII 7 บิต^{[ 3 ] [ 4 ] [ 5 ] [ 6 ]}

ต่อมา รูปแบบของข้อความอีเมลได้รับการกำหนดใหม่เพื่อรองรับข้อความที่ไม่ใช่ข้อความ US-ASCII ทั้งหมด (ข้อความในชุดอักขระอื่นที่ไม่ใช่ US-ASCII และข้อความที่ไม่ใช่ข้อความ เช่น เสียงและรูปภาพ) ^{[ 6 ]}ฟิลด์ส่วนหัว Content-Transfer-Encoding=binary ^{[ a ]} ​​ต้องการการขนส่งที่สะอาด 8 บิต

RFC 3977 ^{[ 7 ]}ระบุว่า "NNTP ทำงานบนช่องสตรีมข้อมูลแบบสองทิศทางที่เชื่อถือได้กว้าง 8 บิต" และเปลี่ยนชุดอักขระสำหรับคำสั่งเป็นUTF-8อย่างไรก็ตาม RFC 5536 ^{[ 8 ]} ยังคงจำกัดชุดอักขระไว้ที่ ASCII รวมถึง การเข้ารหัส MIME ของข้อมูลที่ไม่ใช่ ASCII ตาม RFC 2047 ^{[ 9 ]}และ RFC 2231 ^{[ 10 ]}

โดยทั่วไปแล้ว ชุมชนอินเทอร์เน็ตจะเพิ่มคุณสมบัติโดยการขยายทำให้สามารถสื่อสารได้ทั้งสองทิศทางระหว่างเครื่องที่ได้รับการอัปเกรดและเครื่องที่ยังไม่ได้รับการอัปเกรด แทนที่จะประกาศว่าซอฟต์แวร์รุ่นเก่าที่เคยเป็นไปตามมาตรฐานนั้นเสียหายและกำหนดให้ซอฟต์แวร์ทั้งหมดทั่วโลกต้องได้รับการอัปเกรดเป็นมาตรฐานล่าสุด วิธีที่แนะนำในการใช้ประโยชน์จากลิงก์ 8 บิตที่สะอาดระหว่างเครื่องคือการใช้ส่วนขยาย ESMTP ( RFC 1869 ) 8BITMIME ^{[ 11 ] [ 12 ]}สำหรับเนื้อหาข้อความและส่วนขยาย SMTP SMTPUTF8 ^{[ 13 ]}สำหรับส่วนหัวข้อความ ถึงกระนั้นตัวแทนการถ่ายโอนอีเมล บางตัว โดยเฉพาะEximและqmailจะส่งต่ออีเมลไปยังเซิร์ฟเวอร์ที่ไม่ได้ประกาศ 8BITMIME โดยไม่ต้องทำการแปลงเป็น MIME 7 บิต (โดยทั่วไปคือการแปลงquoted-printableหรือ "QP conversion") ตามที่RFC 6152 กำหนด ทัศนคติ "ส่ง 8 บิตไปเลย" นี้ ในความเป็นจริงแล้วไม่ได้ก่อให้เกิดปัญหาในทางปฏิบัติ เพราะเซิร์ฟเวอร์อีเมลสมัยใหม่เกือบทั้งหมดเป็นแบบ 8 บิตที่สะอาด^{[ 14 ]}  

• 32 บิตสะอาด
• MIME § การเข้ารหัสการถ่ายโอนเนื้อหา
• เทลเน็ต