--- title: "Why free PPT-to-SCORM tools fail on mobile (and how to tell before your learners do)" description: "Font embedding, SVG tspan rendering, and one specific browser feature that quietly destroys your course mid-lesson. Notes from too many conversions we've had to redo." canonical_url: "https://ppt-to-scorm.com/blog/why-free-ppt-to-scorm-tools-fail-on-mobile" last_updated: "2026-04-25" --- Free PowerPoint-to-SCORM converters fail on mobile for four specific reasons: SVG ``-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 ``-chopped text This is the failure mode behind half the entries in [5 SCORM errors that break PowerPoint conversions](/blog/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 `` 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 `` 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 `` 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 `` 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:** `` 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 `

`/`

`, or are they styled `
`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.](/quote)