How to Send Presentations With Videos and Fonts Intact
Prepare a presentation for another computer by checking fonts, embedded or linked videos, playback, and backup formats before sharing the files.
Published · Updated November 2, 2026 · 5 min read
To send a presentation that works on another computer, check more than the slide file. Fonts, videos, linked resources, and the playback application can change the result. Test a delivery copy, then share the package through FileFlap with the intended opening instructions.
Ask whether the recipient needs to edit the slides, present them live, or simply review the content. Confirm the application and operating system used at the destination. A slide deck that looks correct in your editor may behave differently in a browser viewer or another presentation program.
For review, include a PDF as a visual reference when useful. It provides a convenient static view, but it does not replace a working slideshow when the presentation depends on animation, audio, or video.
Check the fonts and layout
Custom fonts can be substituted when the recipient does not have them. Microsoft explains how font embedding helps preserve document appearance, subject to application support and font permissions. Check that your chosen fonts allow embedding and test the resulting file.
If the recipient will edit the deck, make sure your font strategy supports their workflow. Do not send font files unless their license permits it. When substitution is necessary, review line breaks, chart labels, tables, and headings after changing fonts rather than assuming the layout stayed intact.
Test videos and other linked resources
Determine whether media is embedded in the presentation or loaded from another file or online location. A local link to your own computer will not be available on the recipient's device. Collect required companion files and preserve the intended folder structure, or use a supported embedding workflow.
Copy the delivery into a separate folder.
Open the copied presentation in the intended application.
Play every video and check sound output.
Check slide transitions and any timed sequences.
Test without internet if the presentation must work offline.
Keep a separate copy of essential media when appropriate, so the presenter has a fallback if playback inside the deck fails. Label it clearly and explain which slide it belongs to.
Send a package with a clear starting point
Name the presentation with a revision number and include a brief README identifying the file to open. Upload the package, test the download, and send the link with enough time for a rehearsal on the destination computer.
Will a ZIP archive fix broken presentation links?
No. An archive keeps files together during delivery, but it does not rewrite references or install missing software. Extract the package and test it as the recipient would before the presentation date.
Rehearse the actual presentation conditions
A presentation may be delivered successfully yet fail during an event because the room computer, display, or audio setup differs from the editing environment. Ask the organizer what equipment will be used and how much setup time is available. Share the deck early enough to run a short rehearsal on that equipment rather than relying only on your own laptop.
Test the opening slide, a dense text slide, a chart, and every media segment. Check whether the presenter can advance slides with the intended controls. If the deck needs internet access, verify that requirement explicitly. If internet cannot be relied on, agree on an offline substitute before the event rather than improvising during the talk.
Prepare useful fallback formats
A static PDF is useful for checking layout and for a presentation that can proceed without animation. A separate video export can preserve a timed sequence when appropriate, but it may remove the presenter's flexibility to move between slides. Choose fallbacks according to how the presentation will be delivered, and explain the tradeoff to the person presenting.
Name fallback files by purpose. Put the editable deck, static reference, and standalone clips in clearly identified folders. Do not make the recipient guess whether a file named final2 is the main presentation or a backup. The README should name one primary starting file and explain when each alternative should be used.
Review hidden or unintended content
Check speaker notes, comments, hidden slides, and embedded resources before distributing a deck beyond the original team. Material that is not visible during a normal slideshow may still be present in the file. Make a separate external delivery copy if internal notes or working slides need to stay with the team.
After removing material, run the presentation again. Deleting a slide can affect the narrative, links between sections, or the expected timing. If the recipient will edit the file, explain which components they can safely replace and which resources are required for the intended appearance or playback.
Issue a controlled final revision
When the final wording changes shortly before an event, avoid sending several equally named attachments through different conversations. Publish a clearly numbered revision and say what it replaces. Ask the presenter to confirm the filename on the device that will actually be used. Keep the approved delivery and its fallback files together. If the organizer downloads the package in advance, a later change needs an explicit notification; updating a transfer does not guarantee that an already downloaded local copy will change with it.
For the delivery itself, you can send files online with FileFlap. Prepare the checked version first and include the filename and intended next step in your message.
