A Word importer reads a document as a series of marked blocks, each one a question, with labeled fields and answers tagged correct or incorrect. When done well, it also lifts your embedded images and puts each one back on the question it belongs to. Six image formats convert cleanly. Two vector formats do not.
This is the file-level companion to migrating a question bank, which covers the project around it. Here we stay inside the document.
Why write exam questions in Word at all?
Because that is where they already are. Academics draft in Word, review in Word, and send tracked changes in Word. Asking them to retype finished items into a spreadsheet adds a step and loses information.
A spreadsheet is a good carrier for a question that is a sentence and four short answers. It is a poor carrier for anything else. A cell flattens paragraphs. It has no natural place for a table, and no place at all for a picture.
Clinical and scientific items are exactly the ones that need those things. A lab-results table, a two-paragraph case, an annotated diagram. If your bank is full of those, the file format is not a detail. It decides how much of each item survives.
How does an importer know where one question ends?
Two approaches exist, and the difference matters more than it sounds.
Some parsers guess. They look for blank lines, numbered lists, or heading styles, then infer where the boundaries fall. This works on a clean document and fails on a real one, because authors use blank lines for emphasis and numbering for answers.
Better parsers require explicit block delimiters: a line that says a question starts here, and another that says it ends. Nothing is inferred. A question that lacks its closing marker fails loudly, naming the marker it wanted, instead of silently merging into the next one.
The cost is that your document has to carry a little syntax. The benefit is that a parse failure tells you which block is wrong rather than producing 40 questions where you wrote 45. Take the vendor's template rather than a blank page, and the syntax comes with it.
Why does the template use a fixed list of field names?
Inside a block, an importer needs to tell a label from prose. The obvious rule — treat anything before a colon as a field name — breaks on the first question that contains a URL, because https:// looks exactly like a label.
So a good parser uses a closed list of recognized field names. Only those words, followed by a colon, count as fields. Everything else is content, colons and all.
The list is short and predictable: a title, the question type, points, difficulty, an estimated time, whether partial credit applies, the question text, instructions, an explanation, a model answer, and the answers themselves. Prose fields run across as many lines as you need.
Answers are marked inline rather than in a separate column. A tagged bracket beside each one says which is correct. That is the whole grammar: blocks, labeled fields, and marked answers.
What happens to the images?
This is where document importers differ most, and where the failure is hardest to spot.
Word does not store a picture inside the paragraph you see it in. It stores image parts separately and references them from the document body. A parser that walks the file and pairs the first stored image with the first question will get a simple document right. On a real one, it gets some of them wrong, because Word's storage order is not reading order. The result is subtle: every image imports, there are no errors, and a handful sit on the wrong questions.
StudyDrome Exam Manager resolves each image by its relationship identifier instead — the reference the document itself uses — so a picture lands on the block that actually cited it. Each image part is converted to PNG and stored, and one picture reused across several questions is attached to each. Drawings that hold no picture, such as shapes and charts, still hold their position, so nothing downstream shifts by one.
Six formats convert: JPEG, PNG, GIF, BMP, TIFF, and WEBP. EMF and WMF do not. Those are the vector formats Office produces when you draw inside Word rather than paste a picture in. They fail per image, with a warning naming the format, and the rest of the parse continues. That behavior is deliberate: an art problem in question 30 should not cost you the other 44.
The practical consequence is worth acting on before you upload. If your diagrams were drawn with Word's own shape tools, they are probably EMF or WMF. Paste them back in as PNG.
What does a document give you that a spreadsheet cannot?
Three things, and they are the reason to choose this route at all.
Structure inside a question. Tables and paragraph formatting are carried through as markup, in the order they appear. A results table stays a table.
Length. Prose fields span multiple lines, so a case vignette or a model answer arrives whole rather than crushed into a cell.
Pictures, in place. The image travels with the question that used it, which is the entire point.
A spreadsheet answers the opposite need. One row per question, fixed columns, answers side by side. For a large set of short items, it is faster to fill, easier to sort, and easier to check at a glance. Neither format is better. They suit different banks, and most institutions end up using both.
Where does Word import stop?
Four limits, all worth knowing before you plan the work.
Question types. Only five types import from a document or a spreadsheet: single-answer multiple choice, multiple-response, true/false, short answer, and essay. The product supports eleven types once items are in the bank, but the other six are authored rather than imported, and clinical stations have their own importer entirely.
One file format. .docx only. An older .doc file needs converting first.
File size. Documents with images grow quickly, which is why the ceiling for question import is roughly 10 times that of the other importers. It is still a ceiling; split a very large bank into batches.
No duplicate checking. Nothing compares an incoming question against what is already in the bank. A bank merged from three departments arrives with its duplicates intact, and finding them afterward is a manual job.
Preparing the document: a checklist
Before you upload | Why it matters |
|---|---|
Start from the downloadable template, not a blank file | The markers and field names have to match exactly |
Check every block has both a start and an end marker | A missing closing marker is the most common parse failure |
Replace art drawn inside Word with PNG or JPEG | Vector formats do not convert, and warn per image |
Convert any | The older format is not read |
Mark exactly one correct answer on single-answer items | Validation rejects the row otherwise |
Split very large files into batches | Embedded images reach the size ceiling faster than you expect |
Set aside the types that cannot import | Five types come through; the rest are authored by hand |
Read the preview, not just the valid count | Errors name the row, and the reason before anything is written |
The last row saves time. A good importer parses first and writes nothing, showing every row with its own errors so you can fix the document and try again. Nothing reaches your bank until you choose a target and confirm.
Frequently asked questions
Can you import questions from a Word document?
Yes, if the document follows the importer's template. It reads a .docx file as a sequence of marked question blocks with labeled fields and tagged answers, and extracts embedded images along the way. Five question types import this way. Start with the downloadable Word template rather than an existing paper, because the block markers and field names must match exactly.
Do images in a Word document survive the import?
Usually. JPEG, PNG, GIF, BMP, TIFF and WEBP are all converted and attached to the question that referenced them. EMF and WMF, the vector formats Word produces when you draw with its own shape tools, are not converted — each one raises a warning naming the format, and the rest of the document still imports. Replace those with PNG before uploading.
Why did my images end up on the wrong question?
Because the parser matched them by document order rather than by reference. Word stores image components separately from the text that displays them, and the storage order is not the reading order. A parser that pairs the first stored image with the first question gets a simple file right and a real one wrong, silently. Resolving each image by its own relationship identifier is what prevents it.
Should you use Word or Excel to import exam questions?
Use a document when items carry tables, long prose, or pictures, because a spreadsheet cell cannot hold any of those well. Use a spreadsheet for large sets of short items, where one row per question is faster to fill and easier to check. Both routes import the same five question types, so the choice is about what your items contain.
How do I import and export questions?
Import runs from the question bank screen: download a template, fill it in, upload it, preview it, then pick a target bank. Export is a separate question and often a narrower one, so confirm it before you commit a bank to any system. The test that matters is whether you can get your questions back out in a usable format, not just your reports.
How do I check my test before my users take it?
Check at two points. At import, read the preview row by row rather than trusting the valid count, because a question can parse cleanly and still be wrong. After building the test, open it as a candidate would see it — that is when a missing image, a broken table, or a mismarked answer becomes obvious.
Where to go next
For the project around the file — what to inventory, what does not travel, and how many passes to plan — see migrating a question bank.
For the step-by-step, see managing question banks and Exam Manager.
An import is also a good moment to review what you are importing. Writing flaw-free MCQs covers what earns an item its place.