ความจุของ QR code: ข้อมูลบรรจุได้เท่าไร ตามเวอร์ชันสัญลักษณ์และโหมดการเข้ารหัส

จำนวนตัวอักษรสูงสุดของ QR code: บรรจุข้อมูลได้มากแค่ไหน

QR code บรรจุได้มากที่สุด 7,089 หลัก อักขระตัวอักษรและตัวเลข 4,296 ตัว 2,953 ไบต์ หรืออักขระคันจิ 1,817 ตัว ตัวเลขสี่ค่านี้อธิบายสัญลักษณ์เดียว คือเวอร์ชัน 40 ที่ด้านละ 177 โมดูล ที่ระดับการแก้ไขข้อผิดพลาด L และเป็นเพดานของรูปแบบนี้ ไม่ใช่เป้าหมายที่ใครควรตั้งไว้

ช่วงที่ใช้งานได้จริงแคบกว่าที่เพดานนี้ชวนให้คิดมาก สัญลักษณ์เวอร์ชัน 40 ที่พิมพ์ตามขั้นต่ำ 0.4 mm ต่อโมดูลของกระดาษเคลือบจะกว้าง 71 mm ก่อนนับขอบว่าง และทุกโมดูลต้องรอดจากการถูกถ่ายภาพ โค้ดขนาดนี้จึงพบในงานทำเครื่องหมายเชิงอุตสาหกรรม และแทบไม่พบที่อื่นเลย

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

เวอร์ชันสัญลักษณ์คืออะไร

เวอร์ชันสัญลักษณ์คือชื่อที่มาตรฐาน QR ใช้เรียกจำนวนโมดูลของโค้ด ไล่จากเวอร์ชัน 1 ที่ 21 × 21 โมดูล ไปจนถึงเวอร์ชัน 40 ที่ 177 × 177 โค้ดเวอร์ชัน V มีด้านละ 4V + 17 โมดูล เวอร์ชันจึงไล่ขึ้นทีละสี่ คือ 21, 25, 29, 33, 37 ไปเรื่อย ๆ

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

จากตรงนี้มีผลตามมาสองข้อ และทั้งสองข้อมักทำให้คนสะดุด ข้อแรก ความจุเพิ่มเป็นขั้น ๆ ไม่ใช่ต่อเนื่อง การเพิ่มอักขระหนึ่งตัวอาจฟรี หรืออาจดันโค้ดขึ้นไปเต็มหนึ่งเวอร์ชัน ข้อสอง เวอร์ชันที่สูงขึ้นไม่ได้แปลว่าภาพใหญ่ขึ้น แต่แปลว่าภาพแน่นขึ้น ที่ความกว้างพิมพ์เท่ากัน โมดูลของโค้ดเวอร์ชัน 10 แคบกว่าโมดูลของโค้ดเวอร์ชัน 4 ราว 40% คือมี 57 ช่องในพื้นที่เดิมแทนที่จะเป็น 33 ช่อง และโมดูลเล็กนี่เองคือวัตถุดิบของความล้มเหลวในการสแกน

อีกทั้งไม่ใช่ทั้งสัญลักษณ์ที่ว่างให้เนื้อหาใช้ ในโค้ดเวอร์ชัน 1 มี 233 โมดูลจาก 441 โมดูลที่เป็นลายทำหน้าที่และข้อมูลรูปแบบ ไม่ใช่ข้อมูล ลายระบุตำแหน่งและกายวิภาคของ QR code อธิบายว่าโมดูลเหล่านั้นไปอยู่ตรงไหน ส่วนที่เหลือจึงถูกแบ่งกันระหว่างข้อมูลของคุณกับการแก้ไขข้อผิดพลาดของมัน

โหมดการเข้ารหัสทั้งสี่ของ QR

โหมดการเข้ารหัสคือวิธีที่ QR code ใช้แปลงอักขระเป็นบิต และมาตรฐานกำหนดไว้สี่โหมด คือ ตัวเลข ตัวอักษรและตัวเลข ไบต์ และคันจิ แต่ละโหมดอัดอักขระด้วยความหนาแน่นต่างกัน สัญลักษณ์เดียวกันจึงบรรจุอักขระได้จำนวนต่างกันมาก ขึ้นอยู่กับว่าเนื้อหาเปิดทางให้ใช้โหมดไหน

โหมดที่ควรทำความเข้าใจคือโหมดตัวอักษรและตัวเลข เพราะเป็นโหมดเดียวที่ใช้กับ URL ได้ มันคือวิธีเข้ารหัสแบบ QR ที่อัดสองอักขระลงใน 11 บิต โดยใช้ชุดอักขระ 45 ตัวประกอบด้วยตัวเลข ตัวพิมพ์ใหญ่ ช่องว่าง และเครื่องหมายวรรคตอนแปดตัว ตัวพิมพ์เล็กไม่อยู่ในชุดนี้ และเครื่องหมายคำถาม แอมเพอร์แซนด์ เครื่องหมายเท่ากับ กับขีดล่าง ก็ไม่อยู่เช่นกัน

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

ความจุของ QR code ตามเวอร์ชันและโหมด

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

มีสองช่องในตารางนี้ที่ควรอ่านคู่กัน เวอร์ชัน 25 ที่ระดับ L บรรจุได้ 1,273 ไบต์ และเวอร์ชัน 40 ที่ระดับ H ก็บรรจุได้ 1,273 ไบต์เท่ากันเป๊ะ นั่นคือสัญลักษณ์ที่มีพื้นที่โมดูลมากกว่าสองเท่า แต่ใช้ส่วนต่างทั้งหมดไปกับการกู้คืน ความจุที่ได้จากการขยายโค้ดกับความจุที่เสียไปจากการเพิ่มระดับคือเงินสกุลเดียวกัน และนั่นคือเหตุผลที่การตัดสินใจทั้งสองอยู่ในตารางเดียวไม่ใช่สองตาราง

ทำไม URL เดิมจึงพอดีกับโค้ดที่เล็กลงเมื่อเป็นตัวพิมพ์ใหญ่

URL ที่เขียนด้วยตัวพิมพ์ใหญ่สามารถเข้ารหัสในโหมดตัวอักษรและตัวเลขที่ 5.5 บิตต่ออักขระ แทนที่จะเป็น 8 บิตของโหมดไบต์ นั่นคือการประหยัด 31% และมักทำให้สัญลักษณ์ลดลงเต็มหนึ่งเวอร์ชัน HTTPS://EXAMPLE.COM/MENU ใช้เฉพาะอักขระจากชุด 45 ตัว ส่วน https://example.com/menu ไม่ใช่ เพราะตัวพิมพ์เล็กไม่อยู่ในชุดนั้น

ข้อติดขัดคือมีเพียงบางส่วนของ URL ที่เปลี่ยนเป็นตัวพิมพ์ใหญ่ได้อย่างปลอดภัย สคีมและชื่อโฮสต์ไม่แยกตัวพิมพ์เล็กใหญ่ HTTPS://EXAMPLE.COM กับ https://example.com จึงไปถึงเซิร์ฟเวอร์เดียวกัน แต่ทุกอย่างหลังชื่อโฮสต์แยกตัวพิมพ์บนเว็บเซิร์ฟเวอร์ส่วนใหญ่ การเปลี่ยนพาธเป็นตัวพิมพ์ใหญ่จึงอาจได้โค้ดที่สแกนได้อย่างสมบูรณ์แต่ไปลงที่หน้า 404

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

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

การแก้ไขข้อผิดพลาดคือครึ่งหนึ่งของเรื่องความจุ

การเพิ่มระดับการแก้ไขข้อผิดพลาดจาก L ไป H ตัดความจุของสัญลักษณ์ออกราว 57% เพราะโค้ดเวิร์ดสำหรับกู้คืนกับโค้ดเวิร์ดสำหรับข้อมูลมาจากงบก้อนตายตัวก้อนเดียวกัน ในทุกเวอร์ชัน ทั้งสี่ระดับแบ่งยอดรวมเดียวกัน ระดับ L ใช้ไปกับการกู้คืนราว 7% ระดับ M ราว 15% ระดับ Q ราว 25% และระดับ H ราว 30%

ปฏิสัมพันธ์ที่ทำให้คนแปลกใจยังทำงานในทางกลับกันด้วย เพราะความจุเพิ่มเป็นขั้น ๆ การขยับขึ้นหนึ่งระดับจึงมักไม่มีค่าใช้จ่ายเลย ถ้าเนื้อหาของคุณยาว 40 ไบต์ ทั้งระดับ M และระดับ Q จะพาคุณไปอยู่ที่เวอร์ชัน 4 เหมือนกัน ระดับที่สูงกว่าจึงได้มาฟรี ให้สร้างโค้ดที่ระดับที่เลือกไว้ จดจำนวนโมดูล แล้วสร้างใหม่ที่สูงขึ้นหนึ่งระดับ แล้วเทียบกัน ถ้าตารางไม่เปลี่ยน ให้เลือกระดับที่สูงกว่าเสมอ

ระดับการแก้ไขข้อผิดพลาด L, M, Q และ H อธิบายว่าความสามารถกู้คืนนั้นซื้ออะไรให้จริง ๆ แต่ละระดับรองรับโลโก้ขนาดเท่าไร และทำไมการเพิ่มระดับหลังจากสแกนไม่ผ่านมักทำให้โค้ดแย่ลงแทนที่จะดีขึ้น

จากความยาว URL สู่ขนาดพิมพ์

ความยาวเนื้อหากำหนดเวอร์ชันสัญลักษณ์ และเวอร์ชันสัญลักษณ์กำหนดขนาดที่เล็กที่สุดซึ่งพิมพ์โค้ดนั้นได้อย่างซื่อสัตย์ นี่คือห่วงโซ่ที่มีผลจริงในเลย์เอาต์ และเป็นเหตุผลที่การย่อ URL เป็นการตัดสินใจเรื่องงานพิมพ์ ไม่ใช่เรื่องความเรียบร้อย

สองแถวสุดท้ายรวบเหตุผลของการย่อลิงก์ไว้ในที่เดียว URL ติดตามผลยาว 200 อักขระที่ระดับ H พิมพ์ให้เล็กกว่าราว 34 mm บนกระดาษเคลือบไม่ได้ ส่วน URL ยาว 25 อักขระลงมาถึง 16 mm ได้ ข้อมูลเดียวกัน ส่งด้วยโค้ดแบบเดียวกัน แต่ใช้พื้นที่ไม่ถึงหนึ่งในสี่

ค่าเหล่านี้เป็นขั้นต่ำ ไม่ใช่ข้อแนะนำ โค้ดยังต้องกำหนดขนาดตามระยะอ่านด้วย ซึ่งอยู่ที่ราวความกว้าง 1 cm ต่อระยะสแกน 10 cm และค่าที่ใหญ่กว่าในสองค่านั้นคือค่าที่ใช้ ขนาดต่ำสุดสำหรับงานพิมพ์ พาไปดูการคำนวณนั้นตั้งแต่ต้นจนจบ และเครื่องคำนวณขนาดพิมพ์ QR คำนวณให้ตามระยะที่ระบุ

ทำอย่างไรเมื่อเนื้อหาใส่ไม่ลง

เนื้อหาที่ใส่ไม่ลงในขนาดที่ใช้งานได้ แทบทุกครั้งเป็นปัญหาของ URL ไม่ใช่ของ QR code สัญลักษณ์ทำตามที่ถูกขอไว้ สิ่งที่ขอต่างหากที่ยาวเกินไป เรียงคร่าว ๆ ตามปริมาณที่ประหยัดได้

• ตัดพารามิเตอร์ติดตามผลออก ชุด UTM เต็มรูปแบบพร้อม click ID เพิ่มอักขระ 80 ถึง 120 ตัวเป็นเรื่องปกติ ซึ่งเท่ากับสามหรือสี่เวอร์ชันสัญลักษณ์ด้วยตัวมันเอง ให้แนบข้อมูลแคมเปญที่ปลายทางแทนที่จะฝังในโค้ดที่พิมพ์ออกมา
• ตัด www และเครื่องหมายทับท้ายออก เล็กน้อย ไม่มีค่าใช้จ่าย และมีค่าราวหนึ่งเวอร์ชันบน URL สั้นที่ทุกอักขระมีความหมาย
• ใช้พาธสั้น ๆ example.com/menu แทน example.com/restaurant/our-menus/lunch-menu-2026 บนงานพิมพ์ พาธถูกอ่านด้วยกล้อง ไม่มีใครพิมพ์มันด้วยมือ ความอ่านง่ายของพาธจึงไม่ได้ซื้ออะไรเลย
• ชี้ไปที่การเปลี่ยนเส้นทางที่คุณควบคุมเอง พาธสั้นบนโดเมนของคุณเองที่ส่งต่อไปยัง URL ยาว ช่วยให้โค้ดยังเล็กและปลายทางยังแก้ไขได้ ซึ่งโค้ดแบบสถิตทำไม่ได้ด้วยวิธีอื่น
• เข้ารหัสเท่าที่จำเป็นสำหรับเนื้อหาประเภทนั้น โค้ด Wi-Fi บรรจุชื่อเครือข่าย รหัสผ่าน และชนิดความปลอดภัย ไม่มีอย่างอื่น โค้ดโทรศัพท์บรรจุตัวเลข ฟิลด์ส่วนเกินต้องจ่ายด้วยเวอร์ชัน ดูประเภทของ QR code ว่าเนื้อหาแต่ละแบบต้องการอะไรจริง ๆ
• ลดระดับการแก้ไขข้อผิดพลาด ถ้าไม่มีโลโก้ จาก H เป็น M ไม่ใช่การประหยัดเล็ก ๆ มันเพิ่มความจุเกือบเท่าตัวในทุกเวอร์ชัน จาก 44 เป็น 84 ไบต์ที่เวอร์ชัน 5 และระดับ M เพียงพออย่างยิ่งสำหรับโค้ดที่สะอาดบนกระดาษเคลือบผิวเรียบ
• แบ่งงานออกเป็นส่วน ๆ ถ้าเนื้อหายาวจริง ๆ เช่น เมนู เอกสาร หรือใบรับรอง ให้วางไว้หลัง URL แทนที่จะยัดลงในโค้ด QR code ที่บรรจุ 2,000 อักขระคือโค้ดที่ไม่มีใครสแกนได้

มีอย่างหนึ่งที่ไม่ควรทำ คือเพิ่มขนาดพิมพ์เพื่อให้เนื้อหายาว ๆ ใส่ลงได้ แล้วหยุดแค่นั้น วิธีนี้ได้ผล แต่มันซ่อนต้นเหตุไว้ และงานเวอร์ชันถัดไปจะชนกำแพงเดิมด้วย URL ที่ยาวขึ้นอีกนิดและพื้นที่ที่เหลือน้อยลง

ทำไมขั้นของความจุจึงไม่สม่ำเสมอ

ความจุไม่ได้เพิ่มขึ้นอย่างสม่ำเสมอตามเวอร์ชัน และมีสามกลไกที่แยกจากกันเป็นสาเหตุ การรู้จักมันอธิบายรอยกระโดดที่ไม่อย่างนั้นจะดูสุ่มไปหมดในตารางด้านบน

ตัวบอกจำนวนอักขระกว้างขึ้น ตัวบอกจำนวนอักขระคือส่วนหัวสั้น ๆ ภายใน QR code ที่ระบุว่าเนื้อหามีกี่อักขระ และความกว้างเป็นบิตของมันเปลี่ยนไปตามเวอร์ชันสัญลักษณ์ ในโหมดไบต์ มันกว้าง 8 บิตที่เวอร์ชัน 1 ถึง 9 และกว้าง 16 บิตตั้งแต่เวอร์ชัน 10 ขึ้นไป การข้ามเส้นแบ่งนั้นจึงเสียค่าโสหุ้ยหนึ่งไบต์ก่อนจะเก็บเนื้อหาได้แม้แต่ตัวเดียว

บล็อกของการแก้ไขข้อผิดพลาดถูกแบ่งอย่างไม่เท่ากัน ตั้งแต่เวอร์ชัน 5 ข้อมูลถูกแบ่งเป็นบล็อกขนาดต่างกันเพื่อให้การคำนวณกู้คืนยังจัดการไหว และโครงสร้างบล็อกเปลี่ยนแทบทุกเวอร์ชัน สองเวอร์ชันที่ติดกันจึงอาจได้เพิ่ม 20 ไบต์แล้วตามด้วย 38 ไบต์

มีบิตเศษเหลืออยู่ บางเวอร์ชันเหลือ 3, 4 หรือ 7 โมดูลหลังจากวางโค้ดเวิร์ดครบแล้ว โมดูลเหล่านั้นถูกเติมด้วยศูนย์และไม่บรรจุอะไรเลย นี่เป็นส่วนหนึ่งของเหตุผลที่จำนวนโมดูลกับความจุไม่ได้เดินตามกันเป๊ะ ๆ

ทั้งหมดนี้ไม่ได้เปลี่ยนสิ่งที่ควรทำ แต่มันอธิบายว่าทำไมการเพิ่มอักขระหนึ่งตัวใน URL บางครั้งไม่เสียอะไรเลย และบางครั้งเพิ่มโมดูลอีกสี่โมดูลในทุกด้าน และทำไมวิธีเดียวที่เชื่อถือได้ในการรู้เวอร์ชันจึงคือสร้างโค้ดแล้วนับ แทนที่จะประมาณจากจำนวนอักขระ

เมื่อความจุไม่ใช่ข้อจำกัดที่แท้จริง

โค้ดส่วนใหญ่ชนข้อจำกัดทางกายภาพก่อนจะชนข้อจำกัดด้านความจุอยู่มาก และการเข้าใจสองอย่างนี้สลับกันคือความผิดพลาดที่พบบ่อยในเรื่องนี้ สัญลักษณ์เวอร์ชัน 20 บรรจุได้ 666 ไบต์ที่ระดับ M ซึ่งฟังดูเหลือเฟือจนกระทั่งถึงเวลาต้องพิมพ์ 97 โมดูลต่อด้านที่ขั้นต่ำ 0.4 mm คิดเป็นพื้นที่ 42 mm และเมื่อบีบลงบนป้ายตั้งโต๊ะขนาด 30 mm โมดูลจะเหลือ 0.29 mm ซึ่งต่ำกว่าที่กระบวนการพิมพ์ส่วนใหญ่รักษาไว้ได้ และต่ำกว่าที่กล้องโทรศัพท์แยกออกได้ในระยะยื่นแขน

ข้อจำกัดที่กัดก่อน เรียงตามลำดับที่มักมาถึง

• ขนาดโมดูลบนงานพิมพ์ โมดูลควรมีขนาด 0.4 mm ขึ้นไปบนกระดาษเคลือบ และ 0.5 mm ขึ้นไปบนกระดาษไม่เคลือบ นี่คือสิ่งที่แปลงความยาวเนื้อหาให้เป็นความกว้างขั้นต่ำ และงานออกแบบต่อรองกับมันไม่ได้
• ระยะอ่าน โค้ดต้องการความกว้างราว 1 cm ต่อทุก 10 cm ของระยะห่างจากกล้อง โค้ดแน่น ๆ บนป้ายติดผนังจะล้มเหลวที่ระยะซึ่งคนยืนกันจริง ไม่ใช่ที่ระยะซึ่งมันถูกออกแบบมา
• การโฟกัสของกล้อง กล้องโทรศัพท์มีระยะโฟกัสใกล้สุดราว 10 cm โค้ดที่เล็กมากและแน่นมากบังคับให้คนอ่านเข้าใกล้เกินกว่าที่กล้องจะโฟกัสได้ ซึ่งรู้สึกเหมือนเป็นโค้ดที่สแกนไม่ได้
• คอนทราสต์และผิวสำเร็จ โค้ดที่แน่นทนคอนทราสต์ต่ำและแสงสะท้อนได้น้อยกว่า เพราะแต่ละโมดูลมีพิกเซลน้อยลง ให้ตรวจคู่สีด้วยตัวตรวจคอนทราสต์ QR ก่อนตัดสินใจใช้
• ความละเอียดของไฟล์ส่งออก การส่งออกแบบราสเตอร์ต้องการพิกเซลจำนวนเต็มต่อโมดูล โค้ดแน่น ๆ ที่ขนาดพิกเซลเล็กจะได้ขอบโมดูลที่ฟุ้ง ความละเอียดและ DPI มีวิธีคำนวณไว้ ส่วน SVG เลี่ยงปัญหานี้ได้ทั้งหมด

KoloQR ซึ่งเป็นเครื่องมือสร้าง QR code ฟรีที่มี QR code ทรงกลมและทรงกำหนดเอง ส่งออกได้ทั้ง PNG และ SVG โค้ดที่เนื้อหาบังคับให้ใช้เวอร์ชันสัญลักษณ์สูงจึงวางเป็นงานเวกเตอร์ได้และคงความแม่นยำเชิงเรขาคณิตไว้ที่ขนาดพิมพ์ใดก็ตาม นั่นแก้ปัญหาครึ่งที่เป็นเรื่องการส่งออกได้ แต่ไม่แก้อีกสี่ข้อที่เหลือ เนื้อหาที่ยาวยังต้องการโค้ดที่ใหญ่ขึ้นทางกายภาพอยู่ดี ไม่ว่าจะส่งออกเป็นรูปแบบใด

ความเข้าใจผิดที่พบบ่อยเรื่องความจุของ QR code

ความเข้าใจผิดที่พบบ่อยที่สุดคือการมองค่าสูงสุด 2,953 ไบต์เป็นงบสำหรับใช้งานจริง ค่านั้นอธิบายสัญลักษณ์ขนาด 177 × 177 โมดูลที่ระดับการแก้ไขข้อผิดพลาดต่ำสุด ซึ่งไม่ใช่โค้ดที่ควรอยู่บนเมนู บนฉลาก หรือบนโปสเตอร์ และเนื้อหาที่เข้าใกล้ตัวเลขนั้นจะล้มเหลวด้วยเหตุผลทางกายภาพไปก่อนนานแล้ว ก่อนที่ความจุจะกลายเป็นข้อจำกัด