Why free PPT-to-SCORM tools fail on mobile (and how to tell before your learners do)

Free PowerPoint-to-SCORM converters fail on mobile for four specific reasons: SVG <tspan>-chopped text, broken font embedding, Chrome's auto-translate destroying the layout, and desktop-sized tap targets. Most clients who come to us for a re-do have hit at least two — usually after their learners (half of them on phones at 11pm finishing mandatory training) start reporting scrambled slides, missing text, and translated-then-broken layouts.

Here's what each looks like and how to test for it before your learners do.

1. They export slides as SVG with <tspan>-chopped text

This is the failure mode behind half the entries in 5 SCORM errors that break PowerPoint conversions. Most converters try to "preserve fidelity" by exporting every slide as an SVG. That's fine in principle — until you look at how PowerPoint text gets serialised. Each line, sometimes each word, gets its own <tspan> element with hard-coded x and y coordinates.

On desktop browsers at the tool's tested zoom level, it looks identical to PowerPoint. On mobile:

• Pinch-to-zoom scales the whole SVG, which is fine — except on iOS Safari, long <tspan> sequences sometimes render on top of each other at non-integer zoom levels.
• Accessibility zoom (a blind spot — your visually impaired learners are using it) exposes the <tspan> cracks immediately.
• Screen readers read the DOM order, not the visual order. A slide with a heading in the bottom-right and a body block on the left — common in PowerPoint — reads in the order the converter emitted it, which is usually a mess.

The fix: reflow text into actual HTML blocks at conversion time, not SVG <tspan> sequences. We do this as part of every Enhanced-and-up conversion. It takes a bit longer and the slide isn't pixel-identical to PowerPoint — but the slide also isn't broken.

2. They don't embed fonts properly

PowerPoint has the concept of "embed fonts". Most converters honour it, sort of — they pull the font file out of the .pptx and ship it alongside the SCORM package. Then:

• The font path is relative to the wrong root, so the LMS can't find it.
• The font is embedded without subsetting, bloating the SCORM zip to 200MB.
• The font's licence doesn't permit web embedding, and the converter silently omits it without telling anyone.

All three of these cause the same symptom: learners see a system font substitute, layouts reflow wrongly, buttons end up on line two, quizzes become unclickable.

The fix: audit every font in the source deck at quote time. Substitute web-safe fonts at conversion time if any of the embedded ones can't be shipped legitimately. Subset everything you do ship.

3. Chrome auto-translate destroys the layout

This is the one most teams have never heard of. Chrome's built-in Translate feature mutates the DOM — it replaces text nodes with translated text nodes, reflows containers, and if your slides are positioned absolutely (which they are, after any SVG-based conversion), the translated text overflows in ways the original positioning can't accommodate.

Even better: some LMS mobile views set lang attributes incorrectly, so Chrome thinks an English course is in (say) Dutch and tries to translate it. The result is a course in broken machine-translated Dutch that no-one ordered, with text spilling over quiz buttons.

The fix: <meta name="google" content="notranslate"> and translate="no" on containers that must not be touched. We do this on every conversion. It's one line per slide. Free converters don't add it because nobody told them.

4. Tap targets are desktop-sized

PowerPoint shapes have whatever click area the shape has. Converted to SCORM and viewed on mobile, a tastefully small "Next" chevron becomes a 24-pixel target — below the WCAG minimum of 24×24 CSS pixels for adjacent controls, and below the 44px Apple Human Interface Guideline for mobile. Learners report that the button "doesn't work". It works; their fingers are bigger than 24 pixels.

The fix: enforce a minimum 44×44px hit area for all interactive elements at conversion time, regardless of what the source PowerPoint says.

How to tell before your learners do

If you're evaluating a free or cheap converter, run this checklist before you commit:

1. Convert one slide. Open the SCORM in Scorm Cloud. Does it look right? (Yes, usually.)
2. Open it in iOS Safari on a real iPhone, not simulator. Pinch-zoom in and out. Anything overlapping?
3. Enable Chrome Translate on Android. Does the layout survive?
4. Open the SCORM zip and look at the HTML. Are headings structured with <h1>/<h2>, or are they styled <div>s? Does tappable UI have ARIA labels?
5. Check the zip size. If a 20-slide deck produces a 50MB+ SCORM, you've got bloated or unsubsetted fonts.

If anything fails the checklist, don't ship.

What we do

Every conversion we deliver is tested against:

• iOS Safari (current + 2 previous)
• Chrome Android with Translate toggled on
• Chrome desktop with 200% browser zoom
• VoiceOver on macOS and NVDA on Windows

The extra hour per deck is the difference between a course that works and a course that generates support tickets.

If you've got a deck that fails any of the above, we can probably fix it. Get a quote.